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Introduction 


This book is meant to fulfil a dual purpose. Besides trying to help you write 
good, sound educational programs of your own, we also hope it will help you 
develop ideas about those programs you can buy and enable you to assess 
them in both educational and programming terms. The term ‘educational’ 
means very different things to different people and they are quite within their 
rights to question everything that we, or any other so-called educationalist, 
might say. Such questioning is healthy, both for individuals and those 
involved in education as a profession, for it is the only real way that education 
can move forward and change for the future. | 

What then of computers in education? There is still a great deal of work and 
research yet to be done, not only on how to use them properly and fully, but 
also on whether they actually perform as people believe and hope they do. 
There has been such a short space of time between the development of the 
technology and its introduction into schools that at the moment we don’t 
know if they truly help or hinder the educational endeavour. Schools are still 
struggling both with the workings of the machine and to find ways in which 
the technology can be used, or best used. We have both met many times the 
adult who has been told that a computer will be good for their child’s 
educational progress and we are certain that this is not the best way to 
approach the machine. No computer will ever ‘be good’ for a child’s 
education unless that child needs to become familiar with computers for their 
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own sake. What might be good for a child, and his or her education, is the 
software that can be run on a computer. There would be little point in so 
much time being spent on reading, in the early years of schooling, if there 
were no books to make the effort worthwhile. Similarly there is little point 
having a computer if there is no good and worthwhile software for the child to 
use on it. This is not to say that there isn’t any good software —'there is of 
course. If you wish to write or adapt some of this software, so that it may 
better help your child, then this book aims to help you do just that. 

Some schools and parents buy computers so that they or their children can 
learn programming and the general principles of computer use and operation. 
This might then form a hobby or even a career for those so inclined. Other 
schools and parents buy the computer so that they can use it to teach or test 
areas of the curriculum other than computer literacy, spelling or maths for 
example. The type of programs used by those with the second purpose in 
mind may be described as application programs and this type of program is 
the heart and purpose of this book. 

This book is not meant to be for a child directly; the aim is to teach and 
encourage parents, teachers and other interested people to write worthwhile 
and appropriate educational programs. We hope the book will be appropriate 
to those involved in every sphere of educational enterprise, from nursery level 
to postgraduate, from special to public schools, and in all disciplines from 
arithmetic to zoology. This may seem a daunting task but we have made life a 
little easier by presenting a text which not only contains programs which are 
ready to run and may be used as they stand or adapted in any way you wish, 
but also contains the building blocks from which other such programs can be 
constructed. 

The building analogy can be taken further. Houses, hospitals and schools 
are buildings designed and used for vastly differing purposes, yet all made up 
of the same basic components, such.as bricks and wood, assembled in a 
variety of ways. This book aims to show you how to ‘manufacture’ the basic 
components, like the bricks of buildings, and then with a specific purpose in 
mind assemble them to provide a program which fits your particular need. 
Just as you wouldn’t expect to buy and use a hospital as a home, you should 
not expect programs to be useful in a vast range of situations. While it is 
possible to design a program for use over a vast range of both ages and 
abilities, as with portable-cabin-type buildings, there is usually a great deal of 
compromise involved; it may make a useful temporary structure, but it is 
unlikely to be the ideal solution in the long term. 


Why the BBC and Electron? 


The BBC Model B and the Acorn Electron computer are- Suitable machines 
for use in both the educational and the home environments. You don’t need 
to take our opinion alone on this subject, as by far the majority of primary 
schools and many secondary schools have decided to use the BBC machine, 
both to teach programming and for other areas of the curriculum. This is not 
simply an accident, but has occurred for sound reasons. 

The BBC has a strong and virtually unbreakable keyboard which helps 
children feel that they can do it little harm. It has one of the most advanced 
and fast BASICs yet written, which means that programming and more 
importantly learning to program become a pleasure and fun rather than a 
chore. It is mainly due to the excellent BASIC command structure that we can 
take the approach to programming that we have outlined above: whilst it is 
not impossible to build programs on other machines in this manner, it is more 
difficult to do so. The BBC is also an extremely flexible machine with a great 
many possible uses. The BBC was designed not only for the home market but 
for educational and small-business use also; this has a very positive benefit for 
the home user, in that the machine has little chance of becoming obsolete as 
so many other home computers have done. The ability to connect second 
processors and a vast range of other hardware items should extend its 
working life almost indefinitely. This book, for example, was written on a BBC 
computer, using a word-processor chip and a printer. 

The Electron has been seen by many to be the BBC computer’s little 
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brother and this is true to a certain extent. It has the same BASIC, a good 
strong keyboard, the same size memory and a very similar operating system. 
It is however a computer system in its own right and shouldn’t be seen always 
as a lesser machine than the BBC. What the Electron lacks in interfaces — 
there are only the cassette, video and expansion provided -— it is likely to not 
only make up for but also exceed the BBC, in terms of peripherals from other 
manufacturers as well as Acorn itself. The expansion port offers the ultimate 
in flexibility to both the owner and designer to make the machine do anything 
they want. It is still early days, but there are already companies offering 
expansion units for joysticks, printers, sideways ROMS and even user ports. 
(If some of these terms are not familiar to you, please turn to Appendix 1 for 
an explanation. ) | 

There are differences between the two machines which you need to be 
aware of. They are summarized after the hardware overview later in this 
chapter. 


What this book expects of you 


This book is not intended to teach you programming from scratch; for 
example we assume that you already know how to put together a working 
program and that you are familiar with most of the commands that BBC 
BASIC supports. We will explain certain of these as we progress but only 
where we are using a command in an unusual way or if the command itself 
has any great interest or peculiarities. This does not mean that you cannot use 
the programs this book contains without knowing how to program — we hope 
that you can — but we have written the book to be more than just a source of 
ready-made programs. We want you to try to design and then write your own 
programs with its help. If, for some reason, you are not yet happy about your 
programming abilities, then there are various avenues open to you. We both 
learned BBC BASIC from the examples in the very well-written manual that 
accompanies the BBC machine, as many others have done in the past, but 
this method of learning doesn’t suit everyone. 

There are several types of evening class available throughout Britain as well 
as correspondence courses that you can take in your own home. We have 
both taught at evening classes and they provide a good atmosphere for 
people to learn in; you are away from the family and have time to use the 
machine with help at hand. This is often the real advantage, in that you can 
yell ‘Help!’ and, rather than find that you have to plough through a vast 
manual, even if it does have an excellent index like the BBC’s, someone is 
there to help you on a one-to-one basis. The BBC Computer Literacy Project 
has an information service with details of all the various schemes and courses 
available around the country. For a stamped addressed envelope they will tell 
you about those in your area or on the particular subject you are interested in. 
(The address is in Appendix 2.) 
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A second assumption that we make is that you have.access to a BBC or an 
Electron computer and can therefore try out the routines and ideas we 
suggest as you read through the book. Computing is an active hobby; in 
terms of mental activity there are few hobbies to beat it. It is perfectly possible 
to read this book in bed or in your favourite armchair but it would be far 
better to read it whilst sitting at the computer, so that you can confirm that 
what we say is true and works on the machine you use at home or school. We 
doubt whether the book and its routines will make much sense to those 
without a machine to use them on. 

We also assume that you have constant access to the manuals supplied 
with the two machines, i.e. BBC Microcomputer System User Guide — later 
referred to as the BBC user quide — if you have a BBC, or Acorn Electron 
User Guide and Start Programming with the Electron if you use an Electron 
machine. If a program mentioned in the text that follows is not one of the 
programs within this book, it will probably be one from the Electron’s 
Introductory Cassette or the BBC’s Welcome Tape which we also assume 
that you have reasonably close at hand. 

A final assumption we make is that you will not try to convert the programs 
and routines in this book to work on other machines. We have written them 
for the two Acom machines described. These machines have so many 
features which cannot be easily converted to other machines, that we don’t 
feel that attempts at conversion are worth the effort. Far better, and more 
educational, would be taking the idea and writing the program again using the 
special features of the machine you are writing for. What is adaptable is the 
type of programming style we advocate — try to adopt the style we suggest 
whenever possible. 


Hardware overview 


It is important to understand the hardware we are to work with. What follows 
is a short but detailed description of the common features of the two 
computers concerned. If any of the terms are not familiar to you, turn to 
Appendix 1 for further explanation. After the common features have been 
explained'there follows a detailed description of the differences between the 
two machines. Where we have to make changes to programs for one or other 
of them, these will be fully explained in the text and in the programs 
themselves. 

The BBC microcomputer and the Electron both share a common central 
processing unit, the 6502. This processor has been available for quite a long 
time now and has been used in many other home computer systems. The 
6502 is an 8 bit microprocessor that can address a total of 65,536 separate 
memory locations or bytes (this is known as 64K, i.e. 64 times 1024; see 
Appendix 1 for further explanation of computer jargon), each of which can 
hold a character, a number or part of a machine-coded instruction. In both 
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the Electron and the BBC all of the available (i.e. all 65,536) locations are 
used for storing programs and controlling the various input and output 
devices that can be connected to the computer. This memory is basically split 
into two sections. 

The lower half of the memory is where the program resides which you, the 
user, load into the machine. This consists of 32,678 bytes (32K) of read/write 
memory (RAM). Unfortunately the operating system and BASIC interpreter 
also need to use this memory and the memory mapped screen is in this area 
too. Consequently the amount of memory available for your programs is 
considerably less than the 32K one might assume. 

The top half of the memory locations contains the operating system and the 
BASIC interpreter. The operating system controls all the input and output 
from the microprocessor itself and the other devices connected to the 
machine. These might-be a tape recorder, joysticks and printers, but always 
include the keyboard and the screen display. The BASIC interpreter is a 
program in the computer that enables you to communicate with it by using its 
language which we call BASIC. It is possible to replace the BASIC interpreter 
with another language or with another application program such as a word 
processor. In fact it is possible to have more than one of these in the machine 
at any one time; they are selected simply by issuing a command from the 
keyboard. They are known as ‘sideways’ or ‘paged’ ROMS. This is made 
possible by all these programs using the same piece of memory and they are 
‘paged’ in and out of that memory space as required. Obviously only one can 
be active at a time but this system of paging enables the computer to be very 
flexible and do much more than would be possible otherwise. 

The keyboard follows the standard layout of most typewriters (known as a 
QWERTY layout due to the arrangement of the top row of keys). Both 
machines provide several special keys, the function keys and the editing (or 
cursor) keys. The function keys allow strings of characters to be fed into the 
computer by pressing just one key; this is very useful and might be employed 
for entering commonly used variable names in programs or sending 
commands without the need to enter them in full every time they are 
required. The editing keys allow any section of the screen to be copied 
quickly, thus making correction or changing of a program line a much simpler 
task. 

The screen display is memory mapped and there are several screen modes 
available. Some of these are text only modes, i.e. they will not take any action 
on the plotting commands a program might contain. These are modes 3, 6 
and 7 on the BBC. The other modes (0, 1, 2, 4 and 5) are all graphics modes 
and offer differing resolutions and colour combinations. Text can also be 
printed in these modes but the number of columns and lines varies from 
mode to mode. By having so many display possibilities the machines can 
cope with a wide range of applications from word processing to arcade 
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games. There is a full description of the facilities offered by each mode in the 
user guides supplied (BBC p. 301, Electron p. 89). 

Programs and data which you load or input to the machine are lost from 
memory when you turn the power off. All home computers need a medium 
to store this information so that it is not lost and can be used again at a later 
date. These machines use ordinary cassette recorders to store their programs 
and they send data to these at a speed of 1200 baud (Appendix 1 for an 
explanation). So that you don’t have to remember to turn the tape recorder 
off after loading, there is a motor control facility too. If you have a remote 
switch socket on your cassette recorder, it can be connected, and the 
computer will then switch the cassette recorder on and off as required. 

There is a built-in sound generator which has the capacity to produce at 
least two sounds simultaneously from the built-in loudspeaker. There are two 
types of sounds available, known as channels. One produces tones and has a 
range of five octaves, whilst the other generates white noise and periodic 
noises and is known as the effects channel. Using both these types.of sound it 
is possible to produce both harmonic and rhythmic effects. 

We have already mentioned the memory that the machine uses and how 
this is split between the languages such as BASIC and the user. The type of 
memory available to the user is called RAM but would be better named 
read/write memory, for that is its capability. There are 32,768 bytes or 
locations of RAM within the machine but they are not all available to you the 
user. The machine uses 3584 of these for its own purposes; they are used to 
keep information about what BASIC is doing and what you have typed in at 
any time, for example. The amount of memory used by the screen is also 
taken from this total. Depending which mode you are in (and ignoring mode 
7 on the BBC), this takes up between 8192 and 20,480 of the locations left. 
This means that you have a maximum of 20,992 (20.5K) memory locations 
left for your program. 

The picture which is generated inside the computer can be displayed on a 
variety of types of television and monitors. There is a fully modulated PAL 
colour television signal which you can tune your ordinary domestic colour 
television to; it is ‘broadcast’ on channel 36, and there are two sockets for the 
connection of specialized video monitors. For black-and-white monitors there 
is a composite video output, and for colour monitors there is an RGB output 
socket. These give differing results depending upon the display you choose to 
connect but the monitor displays are generally the most crisp and accurate. 


Differences between the machines 


The differences between the two machines were reduced to a minimum by 
the design team who originally put together the Electron specification. 
Obviously interfaces are missing as mentioned above and there are some 
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other small differences too. The BASIC in the Electron is almost identical to 
the issue 2 BASIC for the BBC. (BBC owners can find out which one they 
have by pressing BREAK and then typing REPORT and pressing (RETURN). 
If the machine responds with ‘(c) 1982 Acorn’ then you have BASIC 2; if the 
response is “(c) 1981 Acorn’ then you have BASIC 1.) 

The Electron doesn’t have a mode 7 which is a real pity as many 
educational programs for the BBC use this mode a great deal. It has only one 
sound channel, besides the effects channel, but to make things more 
compatible between the machines it accepts sounds for the other channels 
and feeds them all to channel 1. The ENVELOPE command is not as flexible 
as the BBC’s, with only the pitch envelope being definable, and there is only 
on (—15) and off (0) control of sound volume. This means that BBC programs 
using all the channels and special envelopes will run, but will not sound the 
same as they do on the BBC. A surprising omission is the «TV command 
which on the BBC will allow you control of the picture position on the screen. 
This is often used to move the picture lower, particularly on Teletext TVs. The 
Electron has no similar command so the only way to move the picture on the 
screen is by adjusting the television itself. If a program using this command is 
used in an Electron then it is simply ignored but won’t do any harm. The 
Electron has only one tape-loading speed and will not respond to the + TAPE3 
command. It loads at the BBC’s default rate of 1200 baud. 

The final and very major difference is in the speed of the BASIC, especially 
when drawing or printing in the high-resolution screen modes. One 
independent test suggested that the Electron was slower than the BBC by a 
factor of 2.45, i.e. something which takes 100 seconds on the BBC might take 
up to 245 seconds on the Electron. Normally this isn’t a real problem but 
when you are using the high-resolution screen modes it does mean that you 
are far better using machine code routines where possible. 

To summarize, the Electron doesn’t have the following features of the 
BBC: 


Mode 7. 
300 baud cassette speed. 
RS432 interface. 
Analogue to digital converters. 
1 MHz bus interface. 
Tube interface. 
User port. 
Sideways ROMs. 
Printer port. 
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However, all of these, except 1 and 2, can be added by connecting extra 
hardware to the expansion port. 
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What then does the Electron have which is lacking on the BBC? The most 
obvious difference is the facility to give single key entry of ‘twenty-nine 
different BASIC keywords. This is in addition to the programmable function, 
cursor, copy and BREAK keys which both machines share. The other 
difference follows on from this in that if you don’t wish to use the keyword 
entry as provided then you can reprogram the ‘A’ to ‘/’ keys to give other 
results. 


Educational Program Writing 


What do we mean by an ‘educational program’? The words could have many 
connotations depending on our background and thinking. It is possible to 
argue, and many would, that any program you use or write is ‘educational’. In 
the case of many activities, this sort of assertion would be true. If you visit a 
town for the first time, for example, the visit could be said to be educational in 
that you will have learned something you did not know before. 

The Oxford English Dictionary gives the following definition of education: 
‘The systematic instruction, schooling or training given to young people in, 
preparation for the work of life’. This suggests two important characteristics. 
Firstly, is what we try to do with our children systematic? Do we have 
definable aim or purpose in our activities and teaching? And secondly, does 
our work in education prepare our children, and all those learning at 
whatever age, for life? Attempting to answer such questions as these is way 
beyond the scope of this book. However, because of such questions, there 
has been great debate amongst educationalists and those in industry and 
government about the education our schools should provide. 

What has this to do with a book on computer programming? Firstly, we the 
authors, and others concerned with computers in education, have a duty to 
provide material which is both systematic and prepares children for future life. 
We should not provide a hotchpotch of disconnected ideas, selected from 
here, there and everywhere. Poorly planned and poorly executed ‘educational’ 
endeavour has the effect of rendering children easily confused and unable to 


10 


Educational Program Writing 11 


assimilate the knowledge we wish to impart. Without logical or sequential 
order, there is nothing for them to grasp hold of and use to structure the 
knowledge in their memories. Lack of structure is not, however, the only 
problem that could devalue our efforts. We should not provide material or 
knowledge which is too remote from the learners’ concept of reality in either 
style and content or in the approach that we decide to use to teach it. 

This doesn’t mean that there is only one approach to using computers in 
education. Let us consider two very different educational approaches 
suggested by scholars in the recent past, both of which are directly relevant. 
The first approach is known as ‘operant conditioning’ and was developed by 
the American psychologist B. F. Skinner. 

Skinner’s ideas, about how animals, including human beings, learn, 
evolved out of those of the school of classical conditionists who followed from 
Paviov’s experiments on dogs at the turn of this century. From his many 
experiments on both animal and human subjects, Skinner suggested that 
there is a way to maximize the learning of an individual and he drew the 
following conclusions about learning itself: 


1 Steps in the learning process should be short and should develop 
from previous learning. 

2 During early learning, rewards should be given regularly, and during 
other periods there should be continuous and/or intermittent reinforcement 
(i.e. going back over previously learned material to make sure that learning 
is fixed). a 

3 Rewards should follow quickly when the correct fesponse or answer 
is given. 

4 The learner should be given the opportunity to develop and discover 
the rules which lead to likely success. 


A computer could be used to provide for most if not all of Skinnez’s 
learning criteria and hence provide good and efficient learning for all those 
who use them. The machine could be programmed to give practice in very 
small stages of any task at a time and could reward the learner in some way 
for each correct answer or conclusion. It could be provided with remediation 
loops to go back to earlier material to reinforce learning, especially if there is 
difficulty at a present stage. It could also try to explain each stage and the rules 
underlying the concept being taught. 

Skinner believed he could teach almost anything using this approach. He 
said that all the major concepts of arithmetic could be broken down into a few 
thousand stages and taught, in an almost foolproof manner, using a simple 
program. There followed many attempts to automate teaching using 
machinery and programs developed in this way. The machinery of the time 
(1954) was undoubtedly crude, mechanical and complex compared with the 
very advanced and flexible microcomputer technology that this book is 
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about. Many people believe that Skinner’s theories are the best basis for 
much of the educational programming that goes on today; there are plentiful 
examples of this type of approach both in this book and in the growing range 
of educational programs published. 

Other approaches to educational programming have been suggested by 
equally eminent and well-respected theorists. One of these is Seymour Papert 
who concentrates his ideas on the theories of maths teaching. Papert is best 
known for his development of a computer language, especially designed for 
children to use, called LOGO. He takes as his starting point the idea that 
many children are put off maths, as a subject, by the way it is taught. He 
objects to the simple right/wrong approach and the highly directed learning 
which is the very basis of the more Skinnerian ideas. 

Papert in his book Mindstorms suggests that children ‘develop components 
of thinking preconsciously and “spontaneously”, that is without deliberate 
teaching’. This is not fundamentally opposed to the ideas of Skinner. 
Remember that Skinner was interested in maximizing learning; he doesn’t 
discount that children can learn in this ‘spontaneous’ manner, but finds that it 
is less ‘efficient’, in terms of time and recall, than his type of conditioning 
methods. Papert also says, in relation to learning to program, that children 
actually use the knowledge they gain during the programming process: it was 
acquired for a recognizable personal purpose and, because of this, it is a 
source of power to the child. This is a stark contrast to the ideas that Skinner 
proposes. Papert suggests that the use knowledge is put to, and the way in 
which it is obtained, is of value to the child, and not simply the ability to recall 
the knowledge itself. 

Papert describes the value of a computer as, in essence, its ‘universality, its 
power to simulate’. This ‘universality’ is one of the more powerful features of 
such machines, and the role of simulations in computer-assisted learning is 
now increasingly recognized. There are more and more software packages 
being released which allow a computer to model certain situations, especially 
those which in real life might be difficult or costly to use as a learning tool. We 
would in no way decry the writers and vendors of such packages as being 
non-educational. They are likely to develop the powers of thought in unusual 
and interesting ways, but writing such programs is usually beyond the skill of 
the average teacher, parent or other interested party. Therefore in this book 
we concentrate on the more easily written and, we hope, more easily 
understood programs. These usually follow a didactic or drill type of 
approach rather than the more open-ended simulations or modelling 
programs might. 

Some programs in this book do tend more towards a free learning situation 
than to a structured one and the first of these is included in this chapter. 
‘Humber’ involves the thought, decision and mathematical processes 
involved in modern civil engineering. It is far from being a modelling program, 
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though, for there is too little room to include such factors as public opinion, 
political pressures, rehousing and compensation claims. There is still a great 
deal to be gained from the thought processes involved in making decisions of 
this kind. | 

Before we go on to this program, we need to consider what it is that makes 
a good educational program. In order to make the distinction rather more 
clear than words might be, we have written what we could describe as a bad 
though working educational program. There is no need to type this program 
into your computer and we would prefer it if you didn’t. It is simply here as 
the ‘picture’ which is said to be worth a thousand words. It is very short; 
simply by looking at the listing most of the points we wish to emphasize will be 
quite apparent. 


Figure 2.1 A poor educational program 


1@ REM A ‘bad’ times table program 
“OF =@: G=6 
26 CLS 
44 PRINT “WHICH TABLE DO YOU 
WANT TO USE" 
3@ INPUT A 
60 & = RND(1@) 
7@ C = A*B 
830 PRINT “WHAT IS "sAs" * “sB3" “5 
90 G = Gti 
100 INPUT D 


11@ IF D = C THEN PRINT “RIGHT” 
1206 IF D = C THEN F = Fri 
130 IF D = C THEN GOTO 160 


144 IF D<?+C THEN PRINT "WRONG" 
156 IF D<>C THEN PRINT “THE 
RIGHT ANSWER IS "3;C 
160 PRINT "DO YOU WANT ANOTHER GO"; 
176 INPUT ES 
18@ IF ES = “V¥" THEN GOTO 66 
19@ PRINT "YOU GOT "“53;F3" RIGHT 
OUT OF ";G;" TRIES" 
2606 END 


The program does work, so in terms of function it could be called ‘good’, 
i.e. it works. This cannot be said for the bulk of our new programs which don’t 
work when we first start to write them, because they either contain mistakes 
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or are incomplete. Programs at this stage in development can therefore only 
be described as bad in terms of function, but there is hope for them! We need 
to be able to distinguish a program which doesn’t work, i.e. contains those 
illusive ‘bugs’ we are always hearing about, from a program which works but 
does the job in a poor or misleading way. 

There are two main criteria upon which a program can be judged good or 
bad. The first is whether it achieves its aim, if there was one specified; and the 
second is the quality of programming that makes it work. We believe that it is 
easier to judge the second type, as there are some independent standards to 
use as a basis for your decisions. 

The questions you need to answer about the program are as follows: 

1 Does the program work efficiently? 

This question has two real facets to it, in computing terms; they involve the 
twin concepts of speed and memory usage. An efficient program is one which 
does the job required in the minimum amount of time and using the 
minimum amount of memory space. In terms of microcomputing, there are 
other considerations to be taken into account. Firstly it is unlikely that there 
will be another program in the machine that also needs use of the memory! 
Computer programming started in the large mainframe computers used by 
commercial or educational organizations; here the computers were often 
programmed to allow more than one program to be in memory at any one 
time and that meant that there was a great deal to be gained by making your 
programs both as small and as fast as possible. It means savings, in both time 
and money terms, for the organizations who own and run the machines. That 
doesn’t mean there is no need to watch the memory usage carefully, 
particularly on a BBC or Electron, for the less memory you use with your 
program the more you are able to devote to the screen and therefore you 
have greater flexibility about how to organize your screen displays and can 
use more colours or higher. resolution for the graphics. For these reasons we 
still find that the size of a program can be an important indication of its quality. 

Speed is another factor that was of vital importance to the early 
programmers, for the reasons suggested above. The BBC and, to a lesser 
extent, the Electron are fairly fast computers by today’s standards in home 
machines. That doesn’t mean they do things instantly as you might have 
assumed. Therefore we should still try to make our programs as fast as 
possible, and there are many techniques to help us do so. These are 
explained and various utilities are included in Chapters 9 and 10 to help you 
achieve greater efficiency in your programs. 

2 Isthe program itself easy to follow and understand? | 

This is one of the cornerstones of good programming technique and is 
often summed up in the expression ‘well structured’ but it really means more 
than this. It might not seem important to the amateur programmer — sitting at 
home writing a program. to help their child with their weekly spelling test — 
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that a program is easy to follow and understand. They are likely to believe 
that pragmatic considerations are all that matter; i.e. they want to get their 
program completed so that they can use it. The problem comes when they try 
to find the bugs lurking somewhere inside the program which make it stop at 
the most unexpected moment. That is when the structure and thought that 
should have been put into the ideas for the program, before they started to 
write it on the computer, really begin to be missed. For these reasons we 
suggest that there are some essential standards of programming if your 
programs are to be described as ‘good’. 

Firstly, you must be fully aware of the purpose of your program, an idea 
which is taken up in the next chapter. Then you should think clearly about the 
phases you want the program to go through. This process, called analysis, is 
the most vital of the steps when starting to code. After analysis you should 
begin to sort out the physical appearance of your program on both screen 
and printer.-Finally you might start to write the code. If you follow the steps 
outlined above, and in the rest of this book, you should find that your 
program is easy to follow and to understand — for you, at least. 

If you write programs for other people to use or adapt, two other 
considerations or standards are to be followed. They are absolutely essential 
for any program which is to be used by another person but they are well 
worthy of incorporation into all the programs that you write, as they can only 
make life easier in the long run and develop good programming habits too. 

Documentation is the first standard. One of us well remembers, during his 
university days, being criticized for lack of documentation in a program that 
he had written and vowing that his tutor wouldn’t be able to say that again. 
The next program that he wrote comprised about fifteen lines of code and 
one hundred lines of documentation. He had fully explained every part of the 
program in enormous detail and he was then criticized again for his 
extravagant use of memory. During development of any program there 
should be two types of documentation. Firstly there is the paperwork, ideas, 
diagrams, flowcharts, variable lists, glossaries, etc. that you are using, often 
called external documentation; allied to this there should be the internal 
documentation, i.e. within the program itself. This is done by the use of the 
REM statement. Each time you start a new piece or section of program, mark 
it with a REMark to show what it is meant to do and how it is going to achieve 
its purpose. 

Using BBC BASIC means that we have another way of documenting our 
programs. One of the better features of this BASIC is its ability to cope with 
variable names of almost any length, well up to scores of characters, all the 
characters of which are used for identification. This means in real terms that 
you can have one variable called ‘number’, another called ‘numberone’ and 
a third called ‘numbertwo’ and the machine can distinguish between them all. 
This, incidentally, is not possible in many other BASICs; sometimes you can 
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use only two-letter variable names, and in other cases you can use long 
names but only the first four letters are used by the machine to distinguish 
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between variables. 


This feature allows us to document our programs by using meaningful 
variable names instead of the admittedly more usual one- or two-letter names 
used in the program above. That program would be much easier to read 
and would make much greater sense if this suggestion were followed; 
for example, ‘F’ would become ‘numberright’ and ‘G’ would become 
‘numberoftries’. The rest of the variables could be changed in a similar way so: 


that the program would then read as follows: 


Figure 2.2 


10 
20 


REM A ‘better’ times table program 


numberright = @ s 

numberoftries = @ 

CLS 

PRINT “WHICH TABLE DO YOU 

WANT TO USE” 

INPUT testtable 

multiplicand = RND(1@) 

answer = testtable*multiplicand 
PRINT “WHAT IS “stesttables 

“ * “smultiplicands;"™ "3s | 
numberoftries = numberoftries+i 
INPUT reply 

IF reply = answer THEN PRINT 
"RIGHT" ° | 

IF reply = answer THEN 
numberright = numberright+1 

IF reply = answer THEN GOTO 168 
IF reply<>answer THEN PRINT 
"WRONG" 

IF reply<?>answer THEN PRINT 
“THE RIGHT ANSWER [IS “: answer 
FRINT “DO YOU WANT ANOTHER GO"; 
INPUT another got 

IF anothergot = "“Y¥" THEN GOTO 460 
PRINT “YOU GOT "“snumberrights 

" RIGHT OUT OF "“snumberoftries; 
* TRIES” 

END 
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_ It should already be far easier to understand the structure of the program. 
But this doesn’t mean that the program is any different in structure; it would 
need a great deal more work than that! 

This type of program documentation isn’t without its problems, though, as 
it is likely to make programs longer and slower, precisely what we were trying 
to minimize in the discussion above. The way to avoid this is to write 
programs using this method but then to use a special ‘software tool’ or ‘utility 
program’ in order to cut down their length when they are finally completed 
and ready to use. We feel such a utility is so important that we have provided 
one for you to use in Chapter 9. 

When a program is finished and finally debugged there is still some 
documentation to be prepared for those who are to use it. In educational 
programs this is often split into two parts. The first part is for the teacher, 
instructor or other adult who will be using the program and should contain all 
the loading and running information as well as its educational aims and 
objectives. The second part is for the user, and in a well-written program this 
should be kept to a minimum. You should normally aim for the program itself 
to give all the essential information to the user. 

The second, and in our opinion most crucial, feature of programs written 
for others is structure. We have already touched on this area and concept but 
it is impossible to emphasize it too much. Structure can mean the difference 
between being able to salvage a program which is suffering from an epidemic 
of bugs and having to start all over again. The above program is very simple 
but it isn’t well structured at all. The program expects everything to go from 
top to bottom and doesn’t seem to want to branch or deviate from this path in 
any way. It is also obvious that the program has been thought of as a whole 
and hasn’t been split into the various components that lead to the finished 
product. Take, for example, lines 110 to 130. In these lines we are testing the 
same variables three times. This is illogical and slow, for if the test is found to 
be true on the first occasion then it will be true on the other occasions too. 
Similarly there are only two alternatives in any test of equality — it can be true 
or false. Computers find other answers difficult to follow. Therefore the code 
on lines 140 and 150 is also unnecessary for if the test is true at line 110 then 
it will be false at line 140 or vice versa. It would be far better structurally tc test 
just once and then branch to the correct routine before returning to the main 
program further on. 

Once again there is a feature of BBC BASIC which makes this kind of 
branching and structure easy to implement. It is the definable procedure, 
which is dealt with in detail in Chapter 4. Similarly it would show better 
structure for the program to be going around a REPEAT/UNTIL loop rather 
than have a conditional GOTO which returms us to the beginning. With a 
repeat loop we go around the enclosed number of lines UNTIL a certain 
condition is fulfilled; this means that once again the structure of the program is 
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easy to follow as it flows downwards except where a loop occurs. In this 
program the REPEAT needs to be on line 55 and the UNTIL replaces the test 
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on line 180. 


To finish this discussion, here is the program again, with two procedures 
making the structure both better and easier to follow, and a REPEAT/UNTIL 
main program loop. Note that there is now just one test for a correct answer 


(line 110) and no GOTOs. 


Figure 2.3 
10 REM The best we can do so far 
24 numberright = @ ; 
numberoftries = @ 
=@ CLS 
40 FRINT "WHICH TABLE DO YOU 
WANT TO USE" 
306 INPUT testtable 
ao REPEAT 
66 multiplicand = RND(1@) 
7@ answer = testtable*multiplicand 
80 FRINT "WHAT IS “stesttable; 
" # "smultiplicands" "s 
90 numberoftries = numberotftriestl 
190 INPUT reply 
114 IF reply = answer THEN 
PROCright ELSE FPROCwrong 
140 PRINT "DO YOU WANT ANOTHER GO"s 
17@ INPUT anathergot 
18@ UNTIL anothergot = "Y" 
197@ PRINT “YOU GOT “snumberright; 
“ RIGHT OUT OF “snumberoftriess 
*" TRIES" 
2~@0 END 
300 DEFPROCright 
31@ PRINT “RIGHT" 
3220 numberright = numberrightt+l 
330 ENDFROC 
400 DEFPROCwrong 
410 PRINT "WRONG" 
420 PRINT "THE RIGHT ANSWER I5"; 
answer 
420 ENDFROC 
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We are not suggesting that this program is any better educationally — but in 
purely programming terms it is a great deal better than the original was. 


Having considered in detail some of the major factors which show good 
programming, that isn’t enough for educational software assessment. You 
could argue that it isn’t the real point at all. The major faetors to be kept in 
mind when writing educational programs are as follows: 


1 Does the program define and then achieve its educational aims? 

2 Does it make appropriate use of the computer's features, e.g. 
graphics, sound and colour? 

3 Is the user documentation adequate and well written? 

4 Are the on-screen instructions clear? 

5 Is it easy to use? 

6 Isit easy to adapt for the user? 

7 Is the pupil or user well motivated by the program; i.e. do they want 
to use it, is it fun? 

8 Isthe program robust and reliable? 


This type of assessment is of such great importance that we need to devote at 
least a paragraph or two to each of the questions. 

1 Does the program define and then achieve its educational aims? 

There is little point writing a program if you don’t know what you want to 
use it for. So many factors are involved in assessing this that we have made it 
the theme of Chapter 3 where we consider it in great detail. 

2 Does it make appropriate use of the computer's features, e.g. graphics, 
sound and colour? 

This, too, is difficult to assess without a full specification of the aim or 
purpose of the program. If we consider the ‘times table’ program above, 
however, it should be easy to see that there is no real attempt to involve any 
of these features of the microcomputer. Even very minor changes to the 
program would make the whole thing more interesting to anyone using it. 
Many people believe that the motivational aspects of computers in school is 
their greatest asset; they have the ability, with good programming, to take 
what could otherwise be a boring piece of practice and by the use of colour, 
pictures and sound involve the child totally in what they are doing. 

Motivation is not the only use to which these features can be put. Imagine 
teaching note-recognition in music without being able to hear the note itself. 
With a computer there can be the dual aspect of the note being shown on the 
music staff in correct notation — graphics — at the same time as it is played 
through the speaker — sound. In maths programs it is possible to show angles 
as degrees of rotation using moving graphics, something which is very difficult 
to do on paper or chalkboard, or to show the relationship between a variable 
and its graphical representation. This idea is demonstrated to good effect in a 
program supplied to primary schools called ‘Eureka’. Here the child makes 
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decisions about how to organize a bath and can choose to turn on the taps, 
plug or unplug the bath, put the man in or out of it and even have him sing 
whilst in the water. There is then a graph drawn, as the picture develops, 
showing the water level over the time taken. This is a good example of using 
colour, graphics and sound in an appropriate manner. 

3 Is the user documentation adequate and well written? 

Trying to answer this question without running the program is an 
impossible task and therefore this is the sort of question which can be 
answered only during trials with the program. Trialling a program is very often 
missed out by amateur programmers but it is an important step on the path to 
good program writing. After watching a program being used by its potential 
audience (remember to use a group of the right age and ability), you begin to 
see possible ways to improve the program; although it is rare to get a program 
that you are fully content with, you at least know that it works with the 
children it was written for. When running a trial, try to keep a notebook handy 
so that any comments made by the children can be jotted down to study later. 

Try not to answer all the program’s questions yourself: leave the children to 
work some things out for themselves. Similarly resist the temptation to be at 
their shoulder whilst they use the program. Try to leave them to press the 
keys as required. Remember that, in the future, children using the program 
won’t have you there and so will have to rely on the information you have 
given on paper or on the screen. At the end of this type of process you should 
have a good idea of changes which need to be made to both program and 
documentation. After such changes have been made you should trial the 
program again and repeat the process until you are sure it is as good as you 
can make it. 

4 Are the on-screen instructions clear? 

This question also needs to be answered by trialling the program. There are 
a few pointers to be borne in mind at programming time which will make 
displays easier to read. Firstly the writer of the program must employ 
language that the children who will use it can understand. This means 
avoiding long words and long, wordy, sentences if the children are young or 
have reading difficulty. In some cases it might be better to eliminate as much 
of the screen text as possible. Secondly, when the program requires some 
kind of input from the user it is best to tell them what keys are acceptable on 
that occasion and make sure that the program ignores all other input. Finally it 
is important that the text on the screen is readable, and this means choosing 
the right size and style of text. Often this type of choice is dependent upon the’ 
screen mode you decide to use but the appearance of the text is an important 
feature to be taken into account. 

5 Is it easy to use? 

Yet again this might be answered by the trial stage of testing. But by 
minimizing the number of keys needed for program response, and by making 
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sure that only acceptable input is allowed, you can try to alleviate some of the 
likely difficulties. 

6 Is it easy to adapt for the user? 

This has already been touched on in the section on programming but it 
needs to be emphasized that programs which are meant to be altered by a 
user should make such alterations simplicity itself. As an example of this, we 
recently reviewed a spelling checking program for primary-aged children. The 
purpose of the program was that children who didn’t know how to spell a 
particular word would come up to the machine and type in their spelling. 
Then by sorting through the information in its memory the computer would 
suggest a possible correct spelling. There were instructions on how to include 
your own words for correction but their complexity was overwhelming. 
Adding a line meant typing a line number followed by pressing key f0, typing 
your first misspelling, followed by key f2; this step had to be repeated for as 
many misspellings as you thought were possible for that word. It was then 
followed by pressing f2, typing the correct spelling twice and a few other 
function key presses. 

The reason for the difficulty, in this case, was that the programmer hadn’t 
thought the structure of the program through properly; instead of holding his 
data, i.e. the words and their misspellings, in a set of DATA statements he 
held them all in program lines. A little more thought and analysis of the 
program’s aims, especially in relation to user adaptation, would have made 
the whole program much more efficient and usable. This also provides us 
with a good example of program structure affecting the educational quality of 
a program. 

7 Is the pupil or user well motivated by the program; i.e. do they want to 
use it, is it fun? | 

If the purpose of your program is to motivate children to do something that 
they might not enjoy when presented with it in other ways then this is a vital 
concept for you. It is impossible to please all of the children all of the time, but 
we should be sure that we please some of them some of the time, at least. 
Various ways of ensuring this type of motivation are mentioned above in 
relation to graphics, sound and colour. There is always the novel approach to 
be considered, too. If you are to reproduce on a computer a straightforward 
copy of a technique that you already use, then you need to be sure that the 
effort is worthwhile. It would be far better to revise your educational ideas so 
that the purpose is disguised in an attractive way than to do a simple copy. 
Such bright ideas are hard to come by, but the teacher who decides to teach 
the concept of probability using betting odds with a group of young people is 
more likely to have success than the one who decides to use a textbook 
coin-tossing exercise. What is needed is a little more thought and planning — 
keep in mind the part of the dictionary definition of education which mentions 
‘real life’. 
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8 Isthe program robust and reliable? 

This is a very important concept for all those who plan programs for young 
children, although it needs to be bome in mind by other program writers too. 
Before you start to allow others to use your program, you should be as sure as 
you can be that the program is uncrashable. This means that, at all points 
where there is to be some user intervention, the accidental or deliberate key 
press cannot make the program behave in an unacceptable manner. 

The extent to which you should be prepared to take this sort of protection is 
difficult to define, but be certain that in testing a program you try to consider 
the best and worst cases possible. There is an example of this sort of routine in 
the ‘times table’ testing program in Chapter 7. It offers the option of a printout 
of results at the end of a user’s session. If you decide that you want to have 
this type of output, a routine checks that there is a printer attached and 
working. If not, it refuses to accept the command until the printer is working 
or you change your mind. You might say, “Well, who is going to say they 
want a printout if they don’t have a printer?’ We cannot answer the question 
but you must not claim to have a robust program if it ‘hangs up’ because the 
printer isn’t working and you then have to press BREAK to start again. You 
wouldn’t believe how many commercial programs we have seen which don’t 
bother with such checks, and they are much less useful with children because 
of this. 

The aim when you consider this sort of question is to make the program 

‘idiot proof. This should be a major consideration at every stage in the 
programming process. 
To complete this chapter there is an example of a more open-ended 
educational program which, rather than being written to achieve a particular 
and easily defined educational aim, is meant to give an opportunity for 
thought and language development. One might describe it as more 
‘Paperian’ than ‘Skinnerian’ and it may give you some insight into the 
educational possibilities of such programs. We also hope that you will 
appreciate the problems involved in writing this type of program. 

The purpose as far as the children are concerned is to build a road system 
which joins the five towns shown on the grid. The geography of the area is 
such that there are various hazards to be overcome in order to do so. By far 
the biggest of these is the river which has to be crossed at some point in order 
to complete the task. As one might imagine the route which can be built at the 
lowest cost is likely to be the most acceptable to most of those involved. 

For the purposes of this game the area has been divided into hexagons 
which give greater flexibility of direction than a simple square grid would have 
done. It does make the screen printing and the colouring of the hexagons 
rather complex to program, however. Each hexagon has an associated 
building cost dependent upon its location and colour. The vast majority, the 
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black ones, are designated as agricultural land and have a cost factor of £1 
million. The wooded areas are coloured green and cost £2 million per 
location to build a road across. Towns are marked with a ‘T’ and have a cost, 
due to the compulsory purchase problems and the cost of access roads, of 
£10 million. The area of the map covered by the river is coloured blue and 
the cost of building on these locations varies due to the width and depth of the 
river at each point. For this reason all the river locations have their associated 
cost displayed as a number. 

Movement is achieved by pressing the keys ‘A’ to ‘F’ and these represent 
moving to an adjoining location in a clockwise manner. This is displayed as a 
prompt on the screen at all times so need not be remembered. There are 
three other acceptable key presses, though. Pressing f0 causes the movement 
mode to be changed to ‘Clearing’. When moving in this mode any road 
already built which you cross over will be erased and the cost deducted from 
the total. In this mode possible routes can be explored and distances counted 
if you so wish. Pressing f2 places the marker in ‘Building’ mode and any 
location you visit in this case will have a road built upon it — i.e. the colour 
changes to white, and the cost of building that road will be added to the total. 


Figure 2.3a 
Direction ¢ A to F } - ff Movement 
e@arlnd ufekors Building Mode C 


Route cost — £ 86 million. Bey? 
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By judicious use of these two modes it is possible to build and then erase in 
any manner you desire. 

The final acceptable key press is f4 which is used to indicate that you have 
finished the road and wish to leave the program. Your score is then displayed, 
the lower score being, for this game, the ‘better’ score. 

We would suggest that the program is used with small groups of up to four 
children. If it is used in school, then several groups can try to find better or 
cheaper routes and might be encouraged to vocalize their reasons ‘for 
choosing any particular one in preference to another. You could point out, 
after the exercise, that building the road a little way away from riverside 
locations might lead to less flooding, and there are many other facets to this 
problem which will become apparent as you use it. 

There is no ‘correct’ answer and it is arguable as to whether any answer is 
‘better’ than any other. The government when making their decision actually 
chose the most expensive, difficult and spectacular route across the river 
Humber, and another marvel of engineering was created. The only 
requirement the children must fulfil is to join all the five towns, though not 
necessarily to every other town; they may have any number of bridges if they 
wish. Don’t forget your hard-hats, and happy roadbuilding! 


‘Humber’: explanation of program and procedures 


Figure 2.4 


100 MODE 1 
11@ VDU &S 
126 PROCinitialise 
12:0 PROCdraw_grid 
140 PROCinstructions 
15@ PROCfill_ grid 
160 REPEAT 
176 FROCinput_move 
186 IF dir#>="A" AND dirs<="F" 
THEN PROCmove_hex 
196 IF dirt=fOt THEN 
PROCstart_ clearing 
246 IF dirs=f2¢ THEN 
PROCstart building 
218 IF dirt=f4% THEN finished/Z=TRUE 
224 IF building THEN PROCbuild 
258 IF NOT building THEN PROCclear 
240 PROCshow_position 


27@ 
260 
2/@ 
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PROCset_ last 
FROCcost 
UNTIL finishedZ 


28@ PROCend_ game 
2780 END 


This is the main program loop and from this you can begin to see the structure 
of the program. The first statements set the screen mode and join the text and 
graphics cursors ready for the drawing and plotting of the grid. All the 
procedures called are explained in detail below. The master program loop is 
from line 160 to line 270, where the move desired is input and then decoded 
for further action. This loop is terminated only when the finished key (f4) is 


pressed. This then calls the end of program routine. 


Figure 2.5 


508 
518 


DEF PROCinitialise 
x IncA=B6: y_inc4Z=44: town4=168: 
cost 4-0 
x of Fset4=44:y_offset4Z=260: 
x start%“Z=18: y_start%Z=1080 
f@#=CHRS £80: f2S=CHRE &B2: 
f4$=CHRE &B4 | 
black%Z=@: blue%Z=1: greenZz=2: 
whi te4Z=3: building=FALSE 
finishedZ=FALSE:s 
xX max “Z=242y_maxZ=17 
x locZ=14:y_loc4=9:last_x4#=13: 
last_yA=9 
posz=(x_locAé-1)+Cy_loc“%—-1) *x_maxZ: 
last posZ=(last_x%4-1)+(last_yZ-1) 
#xX maxZ 
DIM grid 425 
FOR count%Z=@ TO 425 
gridv?Ycount“z=1 
NEXT count% 
VDU 19,1,4,8,0,@ 
VDU 19,2,2,8,0,0 
VDU 23,240,0,0,7,8,16,32,64,128 
VDU 23,241 ,0@,0,224,16,8,4,2,1 
VDU 23,242,128,64,32,16,8,7,0,0 
VDU 23,243,1,2,4,8,16,224,0,0,0 
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480 VDU 23,244,0,0,0,7,15,31,63,127 
49@ VYDU 23,245,0,8,0,224,240, 
248,257,254 
S5@Q VDU 23,246,127,63,31,15,7,8,0,2 
519 VDU 23,247,254,252,248, 
240,2274,0,0,0 
520 full hex#=CHR$ (244) +CHR# (245) 
+CHR# (10) +CHR$ (8) +CHR$ (8) 
+CHRS (244) +CHR# (247) 
S30 hex#=CHR$ (240) +CHR# (241) 
+CHR# (18) +CHRS (8) +CHRS (8) 
+CHRS (242) +CHR# (243) 
540 *FxX225,128 
S50 *#FXi5,1 
548 ENDPROC 


A procedure with this name is found in many programs and has the purpose 
of setting all the variables required by other procedures to their initial values. 
In this instance the program requires space for all the grid data and this is 
dimensioned on line 380. In order to keep memory requirements to a 
minimum this is dimensioned as a ‘byte’ array. This means that 425 locations 
are left for this information. It would have been possible to use an integer or a 
real number array in this case but there would not have been enough 
memory for such arrays. Each location (425 of them) corresponds to one of 
the hexagons in the arid and holds all the information about it, i.e. its colour, 
the cost to build a road across it and whether there is a road built on this 
hexagon at the time. How this is done is explained below. There is a loop, on 
lines 390-410, where all the hexagons are set to be black and with a building 
cost of £1 million as an initial value, some of these will be changed later to 
other values to represent building difficulty or hazards. 

Lines 420 and 430 set up the correct colours for the program to use. There 
are only four available in MODE 1 so we need to set these four to be black 
(colour QO), blue (set to be colour 1), green (set to be 2), and white (3). The 
VDU 23 statements define the character shapes needed later to be characters 
240 to 247. These need to be combined together to form the hexagons and 
this is done on lines 520 and 530. Line 520 sets a string (full_hex$) to be the 
coloured part of the hexagon; 530 sets hex$ to be the white outline. The #FX 
calls on the remaining lines are to set the function keys to give codes not 
available directly from the keyboard, and line 550 flushes the keyboard buffer 
ready for the first input from the user, thereby clearing any accidental key 
pressing. 
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Figure 2.6 


§7@ DEF PROCdraw_grid 
§8@ LOCAL x_loc%,y_locz% 


990 FOR x_loc%#=1 TO x_maxZ% STEP 
FOR y_locZz=1 TO y_max% 


600 
610 


620 


630 
640 
650 
660 
670 
680 
690 
700 


2 


x posz=(¢Cx locZ-1) DIV 2) 


*#x inec“+x startzZ 


y_pos4=Cy_locA-1) #y_inc2z 


+y start% 
MOVE x _ pos%,y_posZz 
PRINT hex? 


x poss=x_ posAzt+x_offsetZz 
y_posz#=y_posAty_offset~z 


MOVE x_posZ,y_posz 
PRINT hex 
NEXT y_locaz” 

NEXT x_locd% 


710 ENDPROC 
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This procedure as its name suggests draws the grid that we need to play the 
game. In order to make this happen more quickly it prints two hexagons in 
each of the locations held in x_loc% and y_loc%. The STEP for the loop is set 
to be 2 because of this double plotting routine. x_max% and y_max% 
represent the edges of the arid. 


Figure 2.7 
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DEF PROCinstructions 
xpos4z=11408: ypos4~=8Ba 


FROChex (xpos%-14, ypos4+16,blackZ) 


MOVE xpos4-S6, ypos“-32 
PRINT "A" 

MOVE xposZ—-56, yposz+26 
PRINT “B" 

MOVE xposZ%,yposit+64. 
PRINT “C" 

MOVE xposZ+56, ypos4ézt+20 
PRINT "“D" 

MOVE xpos4t+56, yposZ—-32 
PRINT "EE" 

MOVE xpos~Z, yposi-64 
PRINT “F" 
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MOVE xpos%-104, ypos%+128 
FRINT “Movement" 
FROChex (1140, 750,green%) 
MOVE 1080,680 

PRINT “Forest” 

FROChex (1140,600,blue%) 
MOVE 1688,53@ 

PRINT "River" 

PROChex (1149,450,black%) 
MOVE 10388,298 

PRINT “Field” 

FROChex (1140,300, black?) 
MOVE 1156,284 

PRINT "T" 

MOVE 10696,220 

PRINT “Town" 

VDU 4 

COLOUR 131:COLOUR @ 
PRINT TAB(@G,2)3; "Clearing Mode" 
COLOUR 3:COLOUR 128 
PRINT TAB(18,2)5 "Building Mode"; 
VDU 5S 

ENDPROC 


Usually a procedure of this name would be a printing of informative text on 
screen routine. There isn’t enough memory for this, so it prints all the 
headings instead (what we used to call a ‘key’ when we learned geography!). 
These headings are updated later to show the various modes we are in when 
moving around the grid. 


Figure 2.8 
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DEF PROCfill grid 
LOCAL posZ,x pos%,y_pos24,colz%,valZ% 
RESTORE 
READ x_pos%,y_pos%,colzZ%,valiz 
IF x _pos4é=-1 THEN ENDPROC 
REPEAT 
pos“z=(x_ posz-1)+ly_posZz-1) 
ex mMaxdz 
grid?possé=col “~Z*&10 
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1180 grid?posAz=grid?postzt+val% 
119@ PROCdraw_hex (x_posZ,y_pos%) 
1206 READ x_posZ,y_pos%,col%,val% 
1210 UNTIL x_posZ=-1 

12706 PROCshow_position 

1230 ENDPROC 


This routine uses those DATA statements at the end of the program to set up 
the screen with the colour and detail. On lines 1140 and 1210 notice that a 
value of —1 is used to terminate the input. This use of terminal values in DATA 
statements is widespread and will be mentioned in a later chapter. Lines 1130 
and 1200 do the READing and they take four DATA values at a time. The first 
two of these are the x and y grid co-ordinates of the hexagon to be plotted; 
col% is used to set the colour of that hexagon, using the colours set in 
PROCinitialize and the final number is the cost of building a road across that 
hex. A value of 10 indicates a town and is shown on the screen as a ‘T’. A 
colour of 2 is a wooded area and these cost double that of agricultural land to 
build a road across. Any unplotted hexagons are left with their original values 
set in the initialization procedure. It should be obvious therefore that by 
changing the numbers in these DATA lines it is possible to change the screen 
map completely; you could experiment to see what happens if you so wish. 


Figure 2.9 


1240 DEF PROCinput_move 

1250 VDU 4 

1260 PRINT TAE(@,@)3 “Direction 

C Ato F ) — “sTAB(24,@); 

1270 REPEAT 

1280 *#FX202 ,32 

12908 *#F X15 

1300 dir2%=GETS 

1318 UNTIL (dir$s="A" AND dirs<="F") 
OR dirts=f0% OR dirs=f2s 
OR dirt=f 4 

1320 PRINT dirt 

1330 VDU 5S 

134@ ENDPROC 
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In this part of the program, the input of moves from the player is requested 
and then checked for valid key presses. The VDU 4 is used to set the machine 
into text mode so that TAB statements can be used — much simpler than using 
and calculating MOVE statements! The VDU 5 puts us back into graphics 
mode again. The +FX202,32 sets the CAPS LOCK to be on so that all input is 
in the upper case. The «FX15 makes sure that any unwanted, accidental key 
presses are ignored by ‘flushing’ the keyboard buffer, and the GET$ transfers 
the key pressed into string variable dir$. Line 1310 is the checking routine 
which will only allow us out of the REPEAT/UNTIL loop when a valid key is 
pressed. 


Figure 2.10 


135@ DEF PROCmove_hex 
1360 LOCAL old _x,new_x 
1370 old_x=x_loc%:old_y=y_locz 
1380 IF dirt="A" THEN PROCmove_A 
1390 IF dirs="B" THEN PROCmove_B 
1400 IF dairs="C" THEN PROCmove_C 
1410 IF dirs="D" THEN PROCmove_D 
1420 IF dirs="E" THEN PROCmove_E 
1430 IF dirs="F" THEN FROCmove_F 
1440 IF x_locd%#<1 THEN x_locZ#=1 
1450 IF x_loc’%>x_max% THEN 
x loce=x_maxZ . 

1466 IF y_loc%’<1 THEN y_locz=1 
1470 IF y_locd’és+y_maxZ THEN 

| y_loc’=y_maxZ% 
1480 posZ=(x loc%-1)+¢y_locZ%—-1) *x_max% 
1490 IF x_locZ%=old_x AND y_locZ%=old_y 

THEN ENDFROC 

1506 last _xAZ=old_ x:last_y4=old_y : 

| last posZ=pos2/ 
13514 ENDPROC 


Decoding the movement keys is the function of this section. It is called only if 
a valid direction key has been found. After going to the relevant procedure, 
checks are made (lines 1450-1470) to ensure that you haven’t tried to get 
outside the grid (naughty!). Then lines 1480—1500 check to see if you have 
made a valid move within the grid. If you have, then your old locations are 
remembered so that the marker can be removed from that hexagon. 
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Figure 2.11 

1526 DEF PROCmove_A 

13530 IF ¢(x_loc’ MOD 2)=1 THEN 
y_loc’=y_locZz-1 

1540 x_loc%=x_locdz-1 

15520 ENDPROC 


1560 DEF PROCmove_B 

157@ IF ¢x loc% MOD 2)=@ THEN 
y_loc“=y_locd+l 

158@ x_locZ=x_locdé-1 

1590 ENDPROC 


160@ DEF PROCmove_C 
1610 y_locd#=y_locdéti 
1620 ENDFROC 


16346 DEF FPROCmove_D 

1640 IF ¢(x_loc% MOD 2)=0@ THEN 
y_locZ=y_locc%+1 

1650 x _locZ=x_locAétl 

1660 ENDPROC 


1670 DEF PROCmove_E 

1680 IF (x_loc% MOD 2)=1 THEN 
y_locd4=y_locZz-1 

1690 x_locd%=x_locdétl 

1760 ENDPROC 


171@ DEF PROCmove_F 
1720 y_loc%=y_locZ-1 
173@ ENDPROC 
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These are the actual movement procedures which add or subtract the correct 
values from your present location to find your new one. Notice that there is 
no checking for the edge of the grid in these procedures. Why do this six times 
when it can be done after calculation? We therefore save a great deal of 
memory space. 


Figure 2.12 

1748 DEF FROCstart_clearing 

1750 VDU 4 

175@ COLOUR 131:COLOUR @ 

1770 PRINT TAB(@G,2);3; "Clearing Mode” 
178@ COLOUR 3:COLOUR i238 

1770 PRINT TAB(i8,2)s"Building Mode"; 
18@@ VDU 3S 

1810 building=FALSE 

182@ ENDPROC 

183@ DEF PROCstart_building 

1846 VDU 4 

1850 PRINT TAB(@,2)3; "Clearing Mode" 
186@ COLOUR 131:COLOUR @ 

1870 PRINT TAB(18,2)3; "Building Mode"; 
1880 COLOUR 31:COLOUR 128 

1890 VDU 5 

194@ building=TRUE 

1710 ENDPROC 


So that you may both build roads, and change your mind and erase them, we 
need to toggle the two available modes ‘Building’ and ‘Clearing’. All that 
these lines do is set the appropriate mode by altering a logical variable 
(building) and updating the screen to show the new mode. 


Figure 2.13 


1920 DEF PROCclear 

1930 IF NOT FNin_route(x_ locZ%,y_locZ) 

' THEN ENDFPROC 
cost4=cost4-FNvalue(x loc%,y_locZ) 
grid?posé=grid?posz AND &7F 
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FPROCdr aw_hex (x_loc%,y_locZ) 
ENDPROC 


DEF PROCbuild 

IF FNin_route(x locdé,y_locd) 

THEN ENDPROC 

cost 4A=cost/¢ét+FNvalue(x _loc%Z,y_locd) 


grid?’pos4=grid?posdé OR &8@ 
PROCdraw_hex (x _loc%,y_locd%) 
ENDPROC 


These procedures are the routines which either clear or build the road on the 
hexagon of your present location. They both call FNin_route which is the 
function which tests to see if a particular hexagon has already been built on or 
not. In PROCbuild if the hexagon hasn’t been built already then its colour is 
changed and the cost is added to the total. In PROCclear the exact opposite 
occurs; if there is a road it is removed and the cost is deducted from the total. 


Figure 2.14 
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DEF PROCshow_position 

LOCAL x_posZ%,y_pos2Z 

x posZ=FNxpos(x_loc%,y_locz) 
y_posZz=FNypos(x_loc%,y_locdé) 

MOVE x _posZ4+16,y_pos4-16 

IF FNin_route(x_loc%,y_loc%) THEN 
GCOL @,blackz 

PRINT O8 5p 80 

GCOL @,whitez 

ENDPROC 


DEF PROCset_last 
PROCdraw_hex (last_xZ,last_y2) 
ENDPROC 
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These two procedures are used to show your current position on the grid. The 
first changes the colour of the marker (a white asterisk on a white road 
wouldn’t be easy to find!). The second is the routine that removes the marker 
from the last position you visited. This is why we needed to remember in 
.PROCmove_hex what the last location was. 


Figure 2.15 


216@ DEF PROCcost 
2170 VDU 4 
2180 PRINT TAB(@,4)5 
"Route cost —- £ “$ 
STRS(cost“4)3" million. "“ 
2190 VDU & 
2200 ENDPROC 


Obviously enough this prints out the cost of the road built so far! 


Figure 2.16 


2210 DEF PROCend_ game 

2228 VDU 4 

22589 VDU 26 

2244 VDU 26,0,4,30,0 

22v8 CLS 

226@ PRINT "Total cost for the route 
is 6e 

2270 PRINT "£"scost%3" million." 

2284 PRINT’ “Press a key to exit." 

2298 input=GET 

2506 VDU 26 

2o1@ CLS 

25206 ENDPROC 


Using the text window defined on line 2240 this code clears the screen of all 
the information at the top of the grid and prints the total cost of your selected 
route. The program then finishes at the END statement in the main program 
loop. This is not a spectacular end but there is too little room for anything else. 
It is however a good time to call a printer dumping routine if you would like a 
permanent copy of the route you selected. Unfortunately you will have to 
supply this routine yourself. The best place to call it however is on line 2275 


Educational Program Writing 35 


where the screen is relatively clear of all unwanted information. It is likely to 
look like Figure 2.3a. , 


Figure 2.17 
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DEF PROCdraw_hex (x_loc4Z,y_locZ) 
LOCAL x_posz,y_posZ, 
colourZ,valueZ,str$ 

x pos/Z=FNxpos(x_ locZ,y_loacd) 
yY_pos%=FNypos(x_loc%,y_loc®Z) 
colour%=FNcol our (x_loc%,y_loc%) 
valueZz=FNvalue(x_loc%’,y_locd’) 

IF FNin_route(x loc%’,y_loc’) THEN 
colour Z“#=whitez 

PROChex (x_pos“%,y_pos4,colour7) 
strt= et es 

IF FNcolour (x_loc%,y_locd%) =bluez 
THEN str3=STR# (valueZ) 

IF valueZ=townZ THEN str#="T" 

IF FNin_route(x loc%,y_locZ) THEN 
GCOL @,blackZ% 

MOVE x_pos24+16,y_pos24-16 

FRINT str? 

GCOL @,whitez 

ENDPROC 


In order to colour any of the hexagons in the grid, you have first to change the 
grid locations into screen co-ordinates. The purpose of this procedure is to call 
routines to make these conversions and then do the colour changing. It takes 
into account whether a hexagon is in the route, if it is a town or if it is a river 
hexagon needing a value to be printed too. 


Figure 2.18 

249Q@ DEF PROChex (x posZ%,y_pos%,col%) 
2294@ MOVE x _pos%,y_pos% 

2210 GCOL @,col% 

2324 PRINT full hex? 

23958 MOVE x _posZ%,y_posZ% 


2244 GCOL G@,white% 
2uo@ PRINT hex? 


2268 ENDPROC 
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The hexagons have to be printed somewhere and here it is. The method is to 
use the first two parameters supplied to move to the correct location and then, 
using the third, to print a colourful full_hex$. To restore the outside line of the 
grid, this is reprinted in white over the top. Using this method there is no 
chance of ‘holes’ appearing due to slight inaccuracy in the pixel plotting 
routines. If you wish to see what happens if this is not done, delete lines 2530 
and 2550 and then play the game. You should soon see that the grid comes 
to look like a tattered fishing net in a very short time. 


Figure 2.19 


29/70 DEF FNcolour (x _posZ%,y_posZ) 
2986 =(grid?((x posZ—-1)+ ly _posZz-1) 
#x maxZ) DIV &10 ) AND &3 


229970 DEF FNvalue(x_posz%,y_posZ) 
26060 =grid?((x_posZ-1)+(y_posZ-1) 
*x maxZ) MOD &14 


£61@ DEF FNin_route(x pos%,y_pos~/) 
2626 LOCAL nibble% ° 
26380 nibbleAZ=grid?((x_posZ-1) 

+(y posZ-1)%x max“) DIV.&10 
264282 =nibble%twhite% 


This is where the clever maths occur. If you have to use byte arrays due to 
memory difficulties, then one method to squeeze as much information into 
these arrays as possible is the technique of “byte packing’. This is used here as 
each byte (comprising just eight bits) has to contain all the following pieces of 
information: the colour of the hexagon, its building cost, and whether the 
hexagon is already part of the route or not. As we don't use this technique 
very often and there are no other programs in the book involving it, we 
thought you might like a detailed explanation here. 

If you are prepared to believe in such magic implicitly, then you may skip 
this section now and simply marvel at the wonder of technology. 


Byte packing techniques 


Before you can appreciate this technique you need to understand what a byte 
and a bit are. You probably know that a computer memory is made up of 
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many thousands of little switches each of which can be set to on or off. These 
are called bits and when you get a collection of eight of them they are known 
as a byte. Guess what a number less than eight (usually four) is called? Well 
done, a ‘nibble’! Each bit in memory can be set to 1, i.e. on, or 0, ie. off. 
They are called two-state devices because of this. So by combining the eight 
bits and a little elementary binary arithmetic we discover that a number up to 
255 can be stored in just one byte. 

Here we need to store, not one, but three numbers in the one byte, so how 
can this be done? Firstly we must make a list of the maximum values of the 
numbers that we need to store. The hexagon building value can be anything 
from 1 to 10 which can be converted and held in just four bits (2 to the power 
4 equals 16 but 2 to the power 3 equals only 8). The second set of values, the 
colours, can range from 0 to 3 only. They could be represented by just two 
bits (2 to the power 2 equals 4) and so could be coded into just two bits. The 
final value to be stored is the in-route ‘flag’. A flag is a single bit which can be 
only true, i.e. on, or false, i.e. off. This therefore requires only one bit. Adding 
all these bit requirements together comes to 7; this means, if we know a little 
maths, that all these values can be squeezed into a single byte (remember, 
that means eight bits). 

So imagine that you are devising a numerical code to send or store this 
information, it might look something like this: 

Start off by writing down the value of the hexagon as a decimal number. 
For a river square this might be 6 or for a town square it will be 10. 

Add to this a value representing the colour but coded in this way. Colour 0 
= 0, colour 1 = 16, colour 2 = 32 and colour 3 = 48. (Did you notice the 
pattern? Colour 0 = 0 times 16, colour 1 = 1 times 16, etc.) Remember that 
this should be added to the starting value. This is done on line 1170 in the 
program (&10 is the hexadecimal representation of 16; see the user guide for 
more information on hexadecimal). 

Finally there is the ‘already built flag’ to incorporate into the calculation. 
This is done on the following basis: if the hexagon is not already built add 0 
times 128 to the total, i.e. add 0 or even leave it alone! If the hexagon is built 
then add 1 times 128, i.e. 128, to the total so far. 

Just to convince you that the ‘quart into a pint pot’ routine really works, 
let’s take two examples. A river location of value 6, has a colour of blue (1) 
and has been built upon. This means that its value after being converted to 
our code will be: 


6 + (1 times 16) + (1 times 128) 
=6+16+ 128 
= 150. 


Notice that this is not above 255, so it can be contained within the one byte 
easily. 
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If we take a simpler case, a town square has a value of 10, a colour of black 
(O) and hasn’t been built. So its coded value is: 


10 + (0 times 16) + (0 times 128) 
=10+0+0 
= 10. 


All that we need do now is try to explain the maths involved in getting the 
values out of the byte again. But if you can code something you should be 
able to decode it by simply reversing the process. This is all that we do in the 
program, except that to save space — it really is tight, otherwise we wouldn’t 
need to do all this extra work — we use some concepts of ‘Boolean algebra’. 
They simply reverse the coding we have just explained. If you wish to try to 
puzzle it out, see lines 1950, 2010, 2580, 2600 and 2630. 

That’s all there is to it. We bet you have used the technique before! Look 
again at the way that the BBC defines its characters and you will see a byte 
packing technique (admittedly much simpler). 


Figure 2.20 

2650 DEF FNxpos(x posz,y_pos2%) 

2660 LOCAL xposZ 

267@ xposht=((x_pos%—-1) DIV 2)* 
x incdé+x startzZ 

2680 IF (x _poszx% MOD 2)=@ THEN 
xposz=xposAztx of fsetZ 

269@ =xpos% 


2704 DEF FNypos{x posZ,y_posd) 

2716 LOCAL ypos~z 

2720 ypost#=(y_posZ-1)*y_incdt+y_startz 

2730 IF ¢x_ posZ MOD 2)=@ THEN 
yposZ=yposAty_offsetz 

=74@0 =yposZ 


These functions are where the mathematics for the conversion from grid 
location to screen co-ordinated occur. They each return just one of the 
co-ordinate values, either the x or the y value. The maths are too complex to 
explain here but you might be able to work it out given a little time. 


Figure 2.21 
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REM 
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REM Data for river estuary. 


REM 

DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
REM 


2471495 245651,9,24,5; 
2357 aly Py Poy O51 5952555 


20,7,1,9,20,6,1,9,20,5 


2 © &@ 2 4&© @2@ 4S wt 


NWP AOADMWVWVOA 


REM Data for forest / woodland. 


REM 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
REM 


16,17 ,252515,17,2,2514,17,252 
13,17,2,2,12,17,2,2,11,17,2,2 
10,17 52525 %g17 25 258,17 5252 
7,17,2,2,15,16,2,2,14,16,2,2 
13,16,2,2,12,16,2,2,11,16,2,2 
10,16,2,2,9,16,2,2,8,16,2,2 
15,15,2,2,14,15,2,2,13,15,2,2 
127,15,2,2,11,15,2,2,10,15,2,2 
9,15,2,2,8,15,2,2,14,14,2,2 
13,14,2,2,12,14,2,2,11,14,2,2 
10,14,2,2,9,14,2,2,8,14,2,2 
13,13,2,2,12,13,2,2,11,13,2,2 
10,13,2,2,9,13,2,2,13,12,2,2 
12,12,2,2,11,12,2,2,10,12,2,2 
13,11,2,2,12,11,2,2,11,11,2,2 
10,11,2,2,13,18,2,2,12,18,2,2 
12,9,2,2 | 
19,14,2,2,19,13,2,2,19,12,2,2 
19,11,2,2,18,14,2,2,18,13,2,2 
18,12,2,2,18,11,2,2 


REM Data for towns / cities. 


39 


40 Writing Educational Programs 


3178 REM 

3180 DATA 16,14,0,10,5,4,0,10,27,4,0,10 
3198 DATA 18,5,@,18,227,11,0,19 

3200 DATA -1,-1,-1,-1 


This is the data for the various locations, their colours and their values. This 
could have been stored in byte packed format; but so that they are easy to 
change, should you wish, we have allowed ourselves the luxury of using four 
values for each hexagon. They are, in order: x grid location, y grid location, 
colour, and value. By experimenting you should be able to set out a map in 
any way you choose. 


First Catch Your Aim! 


It is staggering to consider sometimes how similar the two areas of teaching, 
on the one hand, and programming, on the other, really are. One of the first 
things you have to learn, in both disciplines, is to put a great deal of thought, 
time and effort into the objectives of your endeavours. There is little purpose 
going into a classroom intending to teach about the inner workings of an 
internal combustion engine and coming out of the same classroom having 
spent all the available time in a discussion of the type of car owned by the 
parents of the children you teach. The lesson may have been one of the ‘best’ 
ones that your pupils can remember, but in terms of reaching the purpose for 
which the lesson was planned, it could be described only as a complete 
failure. 

Similarly, there is the same attention to detail and concentration on the 
objectives required when you first start to plan a computer program. The 
entire discipline of systems analysis is based upon the careful definition of a 
particular process, or system, so that it can be re-designed in some way, to 
gain greater efficiency or lessen errors, or so that it can be implemented on a 
computer at some time in the future. In the writing of educational programs 
such a process is not simply desirable, it is an absolute necessity. 

We therefore offer some suggestions as to the stages of analysis that you 
should consider when you decide to design and then write a particular edu- 
cational program. In order to have an illustration for our discussion we will try 
to design a better ‘times table’ program than the one discussed in Chapter 2. 
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Without a doubt the first area that needs to be considered is the 
specification of the educational purpose of the program. Always keep in mind 
the fact that the use of a computer is ‘the means to the end’ and, in this type 
of situation, never the end itself. So before considering the programming 
problems and niceties, we must first decide the educational priorities. We 
should be able to do this in such a way that the programming becomes easier 
rather than harder. i. 

The first thing you need to write down is a brief description of the purpose 
of your program. Take our ‘times table’ program; such a description might 
read as follows: 


Purpose: to test Jonathan on all the tables up to the last one he learned. 


This would probably be a good start to the whole project, because if we 
analyse this so far we have defined the following areas in either an explicit or 
an implicit way. We know that: 

1 The program is meant to test rather than to teach. 

Obviously if we wanted to write a program to ‘teach’ times tables, we 
would want to incorporate some kind of text or pictorial demonstration of 
what a ‘times table’ is, how one can be constructed, why they are important 
and how they might be learned. Then we could have claimed to have taught 
a little about times tables. Luckily, we are prepared to leave such a task to a 
human being and we have decided to test the learning rather than actually to 
effect it. We apologize for the length of such a discussion but there is 
considerable confusion in the computer world about the difference between 
teaching and testing. If you look at the vast majority of ‘educational’ 
programs, both those available commercially and those printed in books or 
magazines, you will find that, despite being described as teaching programs, 
they are instead testing programs. Most are written to test something already 
known rather than teach something new. Such programs make sure that a 
particular skill is known by a pupil but they will probably be incapable of 
correcting any misunderstanding that the pupil has about the subject. 

2 The program is to be written with a particular person in mind. 

There are certain things about ‘Jonathan’ that we need to know in some 
detail, however. It may be perfectly clear to you who ‘Jonathan’ is and what 
characteristics he displays, but for the purpose of the program it might be of 
great value to analyse these features in a little detail. Firstly we need to assess 
the age of the target pupil, for such is ‘Jonathan’ in this case, and we also 
need to try to decide what educational standard he has reached in this area. 
This will be important later, for if our pupil — or pupils, if you are planning the 
program for a larger group — is exceptionally bright and able then the 
program should be planned to flow a little faster than if we are planning for a 
remedial purpose. 
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3 The program will test tables up to a particular one, i.e. the last one 
learned. 

There are many ways to organize something even as simple as a table test. 
You could test only one table at a time; this would be important when 
learning a particular table for the first time perhaps. You might want to be able 
to select, specifically, certain tables, if they are causing problems for a child: 
Or you may decide, as we have done here, that the pupil has now mastered 
the tables, when presented individually and sequentially, and now there 
needs to be a development of fluency with any of the ‘known’ table problems 
being presented in any order. 

You can see that even from such a short verbal description the program is 
already beginning to take shape. We know some of the requirements we 
would like to fulfil. There is still a great deal more work to be done, though. 
We haven’t yet said how we want the program to appear both on screen and 
to the pupil/s. We don’t know what kind of an approach to take to mistakes, 
whether we want sound and graphics and if so for what purpose; nor do we 
have any idea of how the program is to be finished. 

This all means that further consideration needs to be given to both the 
detail that we have already suggested, and those details that these areas 
haven’t covered. At this stage it would be best to start by making notes of all 
our thoughts, suggestions and ideas, in enough detail to be of use later when 
programming. These notes can be jotted down anywhere, but try not to lose 
them — that brilliant idea is also usually illusive too. If you are like us, you are 
much more likely to forget the great ideas than you are to remember them! 

Now is the time to ‘flesh out the skeleton’ by trying to decide the details of 
the program’s working — still without a single piece of code, or line of BASIC if 
you prefer, being written. With our ‘times table’ program we might want to 
decide how high a table to set as a limit for the program. We suggest that 10, 
12 or 20 are good places to stop, but if you have a routine which can ask the 
user, or teacher, for a limit each time the program is run then you could allow, 
in the program, much larger limits. This is the approach we shall take in our 
program. 

It is time to consider what you are going to do about wrong answers too. 
There are a vast number of approaches that you could take here. You might 
decide that they get only one try as in a ‘traditional’ table test. A drawback of 
this approach is that the chance that the child has to learn from their mistakes 
is reduced and this is a pity. You might give an unlimited number of tries at a 
problem, but this too has difficulties; a child might be put off by not getting a 
question right after a large number of tries, and frustration is the result. To 
stop this, you might allow the child to choose to avoid any question that they 
can’t answer; a problem here might be that a particular problem is avoided 
regularly and therefore never learned at all. Or you might decide, as we have 
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done here, that there should be a limit on the number of tries allowed, after 
which you tell the child the answer, so that they might have time to remember 
it. 

Don’t think that any one approach is ‘right’ and another ‘wrong’. There are 
circumstances where any of these approaches might be ‘better’ than the 
others but it is often a matter of personal taste rather than a strict rule of 
practice as to why one is chosen and the others dismissed. We decided that a 
limit of two tries would be best. We also remembered Skinner at this point 
and decided that it is usually good to ‘reinforce’ the correct answers when 
given. In order to do this the program will display the problem and the correct 
answer even if the child gets it right first time. 

This is also the time to decide whether you are going to use graphics in a 
program and if so what for. In a times table program they might be used for a 
variety of purposes. If this was to be a teaching program, then we might use 
them to show how a table is constructed from say ‘5 lots of 3’ with the 
appropriate number of ‘lots’ moving together to make 15. You could use 
graphics to make the program more attractive and enticing. There are 
examples of this approach later in the book and there are many varieties of 
this type of program commercially available too. We decided on a fairly 
simple table test but with just a little encouragement, so that whilst we didn’t 
want to include a game as a reward, we did want the child’s name to appear 
with a little colour and sound if possible. 

You should also decide at this stage how many questions to ask and how to 
finish asking them. That might seem a funny thing to suggest, but once again 
there is a vast variety of possible manners in which this could be done. It 
would be possible to ask a fixed number of questions, all second tries 
counting towards this figure. You could decide to ask a fixed number, but not 
count second tries, or once again you might like to give the child the choice of 
how many questions to answer. It would also be possible, though not 
necessarily easy, to ask a fixed set of questions in either a random or a 
predetermined order of presentation. The more usual method would be to 
use the random number generating ability of the computer to do the choosing 
of the questions. One problem in this approach is that, by their very nature, 
random numbers are unpredictable: it would be possible to find that within a 
test of a small number of tables, i.e. with a low upper limit set, the same 
question might appear three or more times. If you would prefer this not to 
happen then you need to make appropriate checks, but in this case it is 
fluency that we are interested in and therefore any unexpected repeat of a 
question will cause no problems. 

Finally we need to decide if it is worth trying to write this program in such a 
way that it will be able to cope with those a little older and those a little 
younger than our target audience. There are two differing points of view to be 
taken into consideration here. You might argue that it is always better to have 
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a very clear target to aim for when writing a program such as this; just as a 
‘made to measure’ suit should fit better than one bought off the peg, so we 
would expect to have a program better fitted to our purpose in the end. 
(‘onversely you might argue that you aren’t sure quite what level to write the 
program to, or that the individuals you are planning for would soon progress 
lwyond the current level and then all that effort and planning would be 
wasted. There is justification for both sides of the argument, and it is possible 
to suggest a compromise position. What is needed is a little flexibility without 
loning all those features that make the program worthwhile and enable it to 
fulfil its purpose. To try to plan a program that is going to teach the whole of 
mathematics to everyone would be impossible, but it should be possible to 
write a program that could be used by an age group of three years if the 
subject was maths or English. Generality of programming can be both a 
blessing and a curse! There are a good number of general programs around 
that can do most jobs but for the highly specific purpose that some people 
have in mind there is no substitute for the ‘bespoke’ program. 

What you should be doing at this stage is planning, in detail, how you 
would like someone else to answer the questions posed in Chapter 2. It 
wouldn’t be a bad idea to write out those questions again now and see if you 
have planned the program in enough detail so that you can answer them. If 
you feel that you can do that, then you are probably ready to go on to the 
programming itself and a consideration of the program planning needed 
before you start to write the code. . 

It is easy at this stage, when you feel you have all the’ answers at your 
fingertips, to let things slip away from your grasp, especially if you sit down at 
the computer and try to write the code at a stroke. We have all done it, and 
we all still do it at times, but it is far from ‘cost effective’ in so many ways. The 
old adage holds true: a few minutes’ planning is worth hours of action. Try to 
put it into practice. 


‘Top down’ programming and analysis 


‘Top down’ is the name of the kind of approach we advocate in this book. 
Its use will lead to a much more structured program in the end and your 
programs should also be easier to understand and to maintain. Ease of 
maintenance is desirable in programs just as much as in a car or washing 
machine. Once a program is written it isn’t completely forgotten, and if a 
similar problem manifests itself again then it might be possible to use again 
some of the work you did originally for the first program. That is one of the 
advantages of using both a structured and ‘top down’ approach. 

In this method you try to break the problem down into sections each of 
which can be dealt with separately; i.e. we start with the ideas, aims and 
objectives and work down from them into the smaller components from 
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which they can be achieved. If we take our earlier example again, what we 
need do at this stage is analogous to the drawing of a ground plan for a 
building site. We need to decide where all the major buildings are to go and 
how they will fit together, preferably without the join showing. Just as the 
architect draws plans and views of the finished whole we need to try to draw a 
plan of how our program will look. One of the ways to do this, especially 
when using a structured programming language like BBC BASIC, would be 
to decide what the main program loop might look like in simple descriptive 
terms. Such a list might look like this: 


1 Introduction to program, rules, etc. 

2 Setting up the various options needed later in the program, e.g. 
maximum numbers, sound level. | 

3 The game itself. 

4 Displaying of scores at the end of the questions. 

5 Allowing another go if desired. 


Immediately you can see that we can start to break these parts down into 
even smaller ones for when we start to write the program code itself. We hope 
that you can also see the logical structure of the program and can begin to see 
ways to solve it. 

In programming of this type on the BBC you might already be able to 
decide what each of these program parts can be called, for it looks as if they 
might all become named procedures. But we suggest that you try to break 
them down even more before you do so. In this example we might divide part 
3, the game itself, into the following subsections: 


3a Decide what numbers to use in the question and work out the 
answer. | 

3b Display the question and ask for an answer from the pupil. 

3c Check to see if the answer is correct. If it is indeed correct then say 
so, adjust the score and display the completed problem (notice that 
we decide to display only the right answer, at the specification stage 
of the design). If the answer is not correct, then say so and, if this is 
the first try, go to 3b once more. If this is the second time that the 
answer has been wrong then display the correct answer and adjust 
the score. 

3d_ After ten questions stop and go on to the next section. 


Once again at least one of the subsections can be broken down still further 
before it is ready for coding (section 3c is a likely one). Also at this stage some 
of the code might be used twice in different places. Take the code that 
displays the answer, for example; that is needed in two separate places yet it is 
doing the same job each time. Rather than write it twice, it would be much 
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better if we wrote it in such a way that we could jump into that section just 
when we wanted to, and then come back to where we left off, when that part 
ls finished. That is the essence of this sort of process. We are trying to find 
those parts of the code needed by more than one part of the program, and 
then write them so that they are simple to use, as and when required. 

Don’t feel that this stage needs to be a very time-consuming process. It 
might take you only a matter of minutes, but should be worth hours in saved 
time when you come to write the program code. The programming task 
should now be much simpler. You have a number of small sections to write, 
all of which contribute to the whole; but, if you have been careful enough in 
your breakdown of the task, none of them are too daunting in scope. 

You might start to write parts of the code now, but first you should start to 
consider the use of pre-programmed modules. If we were to recommend an 
approach to program writing, it would be a ‘top down’ method. Using 
pre-programmed modules is more of a ‘bottom up’ approach, so what is it 
doing in this book, and why have we decided to introduce it at this stage? The 
answer, as in most things, is that a compromise is necessary when writing this 
type of program. It would be very pleasant to be able to write purpose-built 
modules for every program but it would also be completely impractical. If we 
use our clothing analogy again, we might like to be able to buy ‘made to 
measure’ shirts to go with our ‘made to measure’ suit, but is it worth the extra 
outlay involved? The difference between shirts and suits is that you are likely 
to be prepared to put up with any slight misfit in a shirt, which i is hidden, but a 
suit is meant to be seen and therefore has to fit well. 

It is the same with this kind of programming. There are parts which need to 
be fitted carefully to the particular purpose we have in mind. But there are 
also parts of a program that are more hidden and which, although there may 
be drawbacks in their use, can do the job very well with a minimum of cost to 
us in time terms. 

For the reasons outlined above we have provided, in later chapters, an 
educational programmer’s ‘toolkit’. In terms of getting the job done, it makes 
things easier and faster. The ‘tools’, or program modules, that we provide 
should enable you to speed up parts of the programming process to a very 
great extent. Take, for example, the problem of user input; in educational 
program writing this poses real problems, as the whole thing needs to be so 
‘well error trapped. This involves making sure that only input acceptable to the 
program is allowed and anything which cannot be acted upon is rejected 
before it gets to the main program and causes problems. We have therefore 
Included two modules to accept inputs from the user, one of which will accept 
just numbers with a fixed number of decimal places if you desire; the other 
accepts string input and changes it to a particular format too. These are fully 
explained later but we hope that you can see how keeping such a set of 
modules can help you write more quickly and easily. All that you need to do is 
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to understand the strengths, and the weaknesses, of the modules involved so 
that you can use them effectively. 

The major danger in the use of such modules is that you start to decide 
which parts of the program can use which module before you have decided 
fully what the program is to do and how. This is true ‘bottom up’ 
programming, deciding upon a solution before you know what the problem 
is. Try to avoid this type of approach, or your programs will suffer badly. The 
use of modules is a real boon in the right place but they must not be allowed 
to take over, or disaster will result. 


Simple program modifications 


There is one further advantage of working in this ‘top down’ manner and 
writing well-structured and -specified programs: programs become easier to 
modify to fit a new, or slightly different, circumstance. We are not suggesting 
that you should write one program and then modify it to fit every possible 
purpose; that would be ridiculous and a long way from the analytical 
approach we recommend — although we might suspect that this is what 
happens in certain commercial software houses. But there are occasions 
when a program written for one purpose might be usable for another slightly 
different one. 

If we take the ‘times table’ program as our example again, we might find 
‘Jonathan’ has grown out of the level of difficulty we originally set, and we 
might like to allow the program to use bigger numbers. If we have kept all our 
original specifications — remember we suggested that you wrote them down — 
then we might be able to make such changes as are required, first in the 
documentation and then from there in the program itself. 

Another simple, and easily possible, change we might need as circum- 
stances alter is to make the program cope with the number bonds instead of table 
facts. Number bonds are all the additions and subtractions up to twenty; they 
are important because they help us to speed up our division and other 
computations, and for this reason it is often recommended that they are 
‘learned by heart’ just like times table facts. With our program, as currently 
proposed, there would be very little problem in making this change too, but 
this presumes that the other specifications are the same as for the original 
program. If they have changed in ways that the program cannot cope with, 
then trying to modify the old one would be pointless and highly frustrating. 

If we take back to the tailor a suit that used to fit us before we lost an 
amount of weight, there is a certain limit up to which alterations are possible. 
Beyond this limit the finished product is likely to be either prohibitively costly 
or so unfit for its purpose that to continue would be futile. Similarly in 
programming: where a change, when specified carefully, is at a fundamental 
level or so fragmented as to require changes throughout the program, then it 
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would probably be better to write the program from the beginning again. You 
might prefer just to remember the way you solved certain difficulties the last 
time you faced them, and then short-cut the process this time by using the 
same or similar solutions. 

By maintaining the practice of ‘top down’ analysis and good program 
specification on paper, several benefits will acrue. The first is that your 
programs will become better fitted to their purpose. They will be more likely 
to fulfil your desires at the first attempt because you understand what you 
want more clearly. The programs, when written, will be easier to read, follow 
and understand besides being easier to write in the first place. More ideas will 
occur to you; as you analyse one idea it is amazing how many possible side 
avenues appear ready for future exploration. Learning new techniques 
becomes easier; you will understand the problem to be solved more clearly so 
that the working of the solution becomes crystal clear also. Finally the whole 
process will become second nature and so easy that you begin to do it 
naturally and with the minimum of thought or effort. 

We have all heard the expression, ‘He (or she) makes it look so easy.’ Well, 
don’t be fooled. It isn’t often any innate skill or predisposition towards 
something that gives such mastery; it is more likely to be a great deal of 
practice and self-discipline — just the things that you will need to write your 
programs this way! 


Structure in Programming 


Throughout the preceding chapters of this book we have been mentioning 
structure in programs as if the meaning of these words was perfectly obvious. 
You may be saying to yourself, ‘Is all this worthwhile? And what does it all 
mean anyway?” : 

To answer the second part of the question first, we need to explain the 
nature, purpose and need for structure in programming and the difference 
between structured programming and ‘top down’ analysis. We hope that you 
already understand what is meant by a ‘top down’ approach to problem 
solving: starting with a large and complex problem and breaking it down into 
much smaller problems until you get to such a stage that you understand not 
only the nature of the original problem intimately but also how, by solving the 
smaller constituent problems, such a major problem can be resolved. If any of 
this is still unclear try reading Chapter 2 again, because it is really important to 
the rest of this book that this is fully understood. 

So why do we need structure in programming and what is it? Structured 
programming is the name given to a set of loose, yet fairly explicit, methods 
for the design and writing of computer programs. You could arque that all 
programs have a structure, so why can’t all programs, written in any manner 
or to any method, be called structured programming? Well, they could, but 
more often than not they would display ‘bad’ structure; i.e. the programs 
would be difficult to follow, maintain and understand. The adjective ‘good’ is 
assumed in most discussions on this subject and so it is here also. Yes, all 
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programs have a structure, but this may be judged good or bad according to 
tlhe standards explained in the following pages. 

The first of the methods leading to good structure in programming has 
already been discussed: ‘top down’ design. So after you have made your 
detailed notes on what the program is to do and how it should do it, we go on 
to the next of the standards: writing the solution with a clear and 
wasy-to-follow structure. This might involve your rewriting your notes in a 
different form or even producing a flowchart. 

Flowcharts are not essential to good programming by any means, but some 
program writers, one of us included, can see a problem more easily when it is 
uxpressed in a graphic form rather than a verbal form. We wouldn’t go so far 
as to recommend their use, but flowcharts might be useful to some readers 
and therefore be worthy of further investigation. Many standard texts on 
computing have chapters on the use and methods of flowcharting. 

You should be aiming in this rewrite to make the method of solution 
explicitly clear. Try to show which part of the solution follows from each 
section and how the various sections link together. To use our example once 
again, there doesn’t need to be too much rewriting, but you might start by 
showing the major subsections at the left-hand side of your paper and leave 
enough room for their subsections to be written at the right of each section. 

It might look like this: 


Structure for times table program 


Introduction 
Initialize 
Show instructions 


Options 
Sound wanted? 
Highest table 
Printout of results? 


Game 
* Loop until 10 questions asked 
Set counters 
Set question 
Get answer 
Check answer 
Give feedback (right or wrong) 
Increment counters 
Display answer 
Return to loop 
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Final displays 
Scores (screen/printer) 
Another go? 
. Display messages 
Get input 


Loop back to game if answer is yes 


There are still details:to be included in this analysis. But because we were s0 
specific when analysing the program, or rather the problem that the program 
is to answer, we can make up such a chart or plan with the minimum of effort. 

When you have made such a plan then it needs to be examined closely to 
see if there are any parts still unclear in terms of their purpose and objectives, 
or if it isn’t obvious how they contribute to the whole program. It is far better 
to do such checking at this stage rather than have to do it while trying to write 
the program itself. If such ambiguities do exist you should try to resolve them 
by analysing the problem and indeed your suggested solution to see if the 
purpose can be made more specific or even if that section of the plan is still 
required. Remember the aim is to plan in as much detail as possible to make 
life easier later. Aim for small ‘chunks’ or sections to be completed and try to 
assign each one a specific place in your plan. 

A criticism of the plan outlined above is that it still doesn’t show how we are 
to arrange it so that the user is allowed only two tries at any particular 
question. It should be obvious where this piece of analysis needs to fit into the 
plan but there isn’t anywhere near enough detail shown on it, yet. 

Rather than do this part of the analysis for you, perhaps you would like to 
decide how you would have done it. If you want to see our arrangement, 
checking the program is the way to do it. If you feel particularly adventurous 
you might try to remove our coding from the program and write your own. 
Another advantage of this type of approach is that such changes should be 
relatively easy to make. 

When you are sure that the structure of your proposed solution is clear, 
what then? You could start to write the program straight away but, before you 
do, try to think of the way that you are going to do it. Another of the standards 
that lead to well-written and -structured programs is the ‘modular form’. By 
this we mean writing the program in small, reasonably self-contained parts or 
sections. It should now become obvious what the purpose of this time spent 
in analysis and design really is. No longer do you need to write your programs 
all at one go because if you didn’t you would forget where you got to! It is 
almost simplicity itself to write a small piece of code to do a particular job and 
then go on to write another one, or even to leave the whole project and come 
back to it later, picking it up from just where you left off. Because each part of 
the program is so carefully specified you understand not only what has to be 
done next but also at what point it is finished and ready to be left. 
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This benefit of a structured and modular approach may need some 
gmphasis. What you need to do when you have written code to fit your 
upecification is to test it in some detail. Happily because you have a careful 
and detailed understanding of the program you know exactly how each part 
of the code should behave and therefore you should know how to test it too. 
An example might be the input and checking of the sound option. Here we 
have asked a question and want to see what the answer is and how to act 
upon it. The only answers that we want to act upon are Yes and No. Often 
yetting young children to type all this is difficult so we might allow just “Y’ and 
'N’. We therefore write a piece of code to do this job. When it comes to 
testing, certain tests need to be performed to know if the code is adequate. 

Firstly we must test the code with the key presses ‘Y’ and ‘N’ and see what 
the result is. Then we might test it with other key presses and see if the code 
reacts as we expect. There is no need to try every key on the keyboard, but it 
ls good practice to try as many types of key as possible, i.e. the alphabetic 
keys, the numeric keys, cursor keys, function keys, RETURN and TAB; but 
there is more to think about yet. What happens if you press two keys at once, 
especially if you press the SHIFT or CTRL and another key at the same time? 
If the code responds correctly then you can be quite happy, but what if the “‘Y’ 
or ‘N’ that our user types is a ‘y’ or an ‘n’ (because the caps lock is off)? We 
would want the code to be able to cope with this too. You really cannot 
expect every user of a program to understand about the keyboard, so it is 
your responsibility to make sure that you cope with all the Possibilities at the 
time you write the code. 

If everything behaves as you expected then you can claim to have tested 
that part of the code and can go on to the next part. If we progress in this way, 
each part of the program being designed, coded and tested individually, 
lingering ‘bugs’ are less likely to manifest themselves at a late stage in the 
program’s development. This can only be a good thing, but it is highly 
dependent upon your methodical approach to testing. After following these 
steps you should soon find that all your code is ready and waiting for final 
testing, which is also made easier by using a good structure. When a bug is 
found you should have some idea in which part of the code it lives; then 
hiring the pest control officer is no longer necessary — you can cope with small 
outbreaks of infestation yourself because you know where to look! 


Why is structure important in educational programming? 


There is little need to dwell on the benefits of structure in terms of ease of 
development and ease of testing. But there are at least two other important 
features to consider. | 

The first is that structure makes program modification easier. Recently one 
of us considered having a house extended to accommodate a growing family 
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and to give extra facilities. The architect we called in suggested various 
alternative ideas but was in no way prepared to commit himself to the 
feasibility of the suggestions or to costing them. The reason for his reticence 
was that he didn’t have a set of builder’s plans for the house — we weren’t 
given any when we bought it — and so he suggested that we have some drawn 
up. When this was done the architect was then prepared to get down to 
details; he now knew all that was involved in each of the suggestions, and he 
could be sure that making this move or that wouldn’t upset the other features 
of the house that were meant to be left undisturbed. 

So it is with program modification. If the structure you are working with is at 
all ambiguous or unclear, there is a greater chance that any change you make 
will affect other areas besides those you wanted to affect. You would be ina 
very different position if you had a clear idea of the structure before you 
started to change things, besides a clear and highly detailed description of the 
changes you wanted to make. Using structured programming techniques 
makes the structure of a program clear to anyone who might want to examine 
it closely. It therefore makes the task of program modification, whether by 
you or by someone else, that much easier. 

The other particular advantage in using these techniques in educational 
programming is that programs become much more readable. To an extent 
this is covered in the section above on modifications, but there are other 
advantages in readability. Take for example a book like this: if we were to 
pack the book full of unstructured programs with short variable names and 
plenty of GOTOs you would have very little chance of learning to write 
programs like these yourself. By taking particular care over the readability of 
our programs we can ensure that as you type them into your cémputer you 
start to understand what they are trying to do. This is very important to the 
purpose of the book, for it was conceived to be about education in two 
spheres. | 

We are trying to suggest ways in which you can use your computer to help. 
educate your child, but we are also trying to use the listings in this book to 
convince you that writing programs in this sort of way is both viable and 
possible, for anyone who wants to try. It may be that if your children start to 
read some of the programs that you have developed for them, they too could 
be impressed by your easy-to-read programs and try to modify them 
themselves! We both know of young people who first started to use 
computers as games machines but after a while the attraction waned and they 
took to reading listings and modifying them to their own purpose. What is 
more, they learned a great deal about how to program as they went along. 
Let’s hope that they developed good habits from their reading rather than 
bad ones. 
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What structures exist? 


Before we go on to look in detail at the program modules that we have 
provided we need to find out what structures there are, in BBC BASIC, to 
help us in our programming. BBC BASIC is a little unusual in the range of 
structures it allows. BASIC was written as a computer language about twenty 
years ago and the initials stand for Beginners All-purpose Symbolic 
Instructional Code. It was written for people with no training in computer 
science, to enable them to learn programming quickly and easily. Despite its 
popularity over the years it has also come in for a great deal of criticism. 

The reason for the vast majority of such comments is that it allows — some 
would say encourages — a programmer to write programs in a totally 
unstructured way. The criticism is a valid one; some of the worst programs 
ever written have been made possible by the BASIC language. Remember, 
though, that the language was written at a time when structure was not a vital 
issue, and it was written for beginners. Since its birth there have been many 
attempts to change BASIC’s nature in all types of directions. This is one of the 
reasons why you cannot run programs for other manufacturers’ machines on 
your BBC and vice versa. 

The BBC when specifying the type of BASIC to be written for their 
machine decided that they too would add to, extend or improve BASIC. The 
particular changes they wanted to make were to allow, and encourage, 
programmers to write in a more structured way. For this reason you should be 
careful about structure as you write, and for the same reason you would find it 
difficult, though not impossible, to convert these programs for other 
machines. The comments that follow therefore are highly machine specific 
and apply to BBC BASIC only. There are similarities between its commands 
and those of other BASIC dialects but here is not the place to explain or 
investigate them. 

The first of the structures available is also one of the most useful: the 
definable procedure or function. It is possible to discuss the two together here 
because there are great similarities between them in use. In fact it might be 
useful to describe their differences first and then talk about them as if they 
were iderttical. 

The critical difference is that a function always ‘returns’ a value after it has 
taken its action. This means that if you wanted to take a number and divide it 
by 2 you could write both a procedure and a function to do it. This is because 
you are trying to get some type of answer or change from one thing, the 
original number or string, to another, the resultant number or string. The best 
way to write a piece of code to do this type of task would be to use a function 
rather than a procedure, as it is likely to use fewer variables and less memory, 
and also to be faster. You could use a procedure but it would be less efficient. 
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There are certain functions built into most BASICs; for example SIN is a 
function because it takes a number, as in SIN(3) and returns an answer 
calculated from the original number. 

Procedures differ in that, although they can do similar tasks, they don’t 
have to return an answer — they can simply perform an action. Take an 
example such as changing the colour of the screen. This could be written as a 
procedure very easily, but it could never be written as a function because no 
answer is expected or required. 

Having made that short digression, the keywords that make definable 
procedures and functions possible are: DEF, PROC, FN, ENDPROC and the 
operator ‘=’. These make programming in modular form simplicity itself, 
because they enable you to see at a glance where a particular piece of code 
begins and ends. Parts of a program written in this way always start with DEF, 
followed by PROC or FN, and the syntax is completed with a word, name or 
letter of your choice. This is particularly useful in that the location in the 
program of such a procedure is totally unimportant. They can be at any 
position, except in the main program loop, and begin at any line number. 
Using such a structure also means that testing becomes easier too; all that 
needs to be done to test such a piece of code is to type its name as a 
command from the keyboard or write a little testing program which calls for 
the procedure or function to take the appropriate action. This means that 
each of the sections of a program can be written, tested, and saved to cassette 
or disc before being put together in the full program. There are details of how 
to do this in Appendix 3, which we recommend that you read before you type 
in any of the procedures or programs in this book. 

A further advantage of BBC BASIC is its ability to handle ‘parameter 
passing’ to procedures or functions. A parameter is the information that you 
give when you call a procedure or function that it is to take action upon. To 
take a rather stupid example, suppose we had a procedure which printed 
blank lines, in fact lines of forty spaces so that it rubs out what is already on 
the screen. The code might look like this (don’t type this into a computer; just 
try to work out what it does): 


Figure 4.1 


156000 DEF FROCblank line (number) 
1301@ LOCAL counter%Z% 

1IS3W20 bHlanksS=STRINGS(40," ") 

130306 FOR counter% = 1 TO number% 
1=H40 PRINT blank? 

15030 NEXT counter% 

12450 ENDFROC 
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After the name of the procedure on line 15000 there is a parameter 
apecified (number%). If you check the code you will see that this is used to 
upecify how many of the blank lines are to be printed. When we use this 
procedure all we need to do is to put, in brackets, after its name the number 
of blank lines that we want to print; the procedure will do the rest. If this were 
not possible, then the line 


Figure 4.2 
S5@ PROCDlank iine (3) 


would have to be written as this: 


Figure 4.3 

‘SQ FROCblank_Linhe 
%S1 FPROCBlank line 

$352 FROCbDlank_line 
{53 FROCblank_line 
4 PROCblank_line 


or to show better structure like this: 


Figure 4.4 

$45 FOR counterx= i TO Ss 
290 FROC blank_line 

455 NEXT counterZ 


There is almost no limit to the number of parameters that you can pass to a 
procedure,-but unfortunately you cannot pass arrays. The use of defined 
procedures with strings cuts down the coding involved enormously. If you 
examine the ‘times table’ program and note the number of calls to 
PROCcentre you will see how flexible this system really is. 

Defined procedures and functions should always be entered by calling 
them by name and must never be entered by using a GOTO statement. This 
ensures that there is only one entry point to a particular module of code and 
that all the variables are set up in the correct manner. This last point is 
particularly important because certain of the variables can be defined as 
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LOCAL. This allows you to use the same variable names in another part of 
the program without causing their old contents to be overwritten. Let’s look 
again at the example above: line 15010 has the keyword LOCAL followed by 
the variable name “counter%’. If you used this variable in another procedure 
or in the main program loop then this will ensure that there are no difficulties. 
When you enter PROCblank_lines the old value of counter%, if there is one, 
is stored carefully away, then the new value is inserted and the program loops 
the required number of times. At the end of the loop, the value that was held 
in counter% is discarded and the variable is set again to the value that was 
stored at the beginning of the procedure. This is an excellent way of avoiding 
variable clashes, but you need to be sure that you don’t want to use the value 
of a variable generated inside a procedure anywhere else in a program. If you 
do need to use a variable in this way, don’t declare it as LOCAL and this, too, 
is perfectly possible. 

Finally user-defined procedures and functions must have an exit, from 
which you return to the main program or to the procedure or function that 
called the one currently being executed. There need not be only one exit, 
though, and if it is easier to exit the code after some test, e.g. an IF/THEN 
statement, this is perfectly possible. User-defined procedures are ended with 
an ENDPROC statement, whilst functions end with an ‘=’ operator. 
Remember that they always return a value so they are always called in the 
following way: 


Figure 4.5 
1250 answer t=FNyes or no 


When this code is executed, the result of the function is placed into the 
variable ‘answer$’ for use later in the code. As with procedures there can be 
any number of exits from a function. 

We hope that you can see from this discussion how BBC BASIC not only 
allows but positively encourages us to write programs in the structured and 
modular manner described. Each part of our program can be coded as a 
procedure or function and then these are called in tum or as required, by 
other program lines. There are other structures available, however, also 
worthy of detailed consideration. 

The first of these is the ‘subroutine’. This type of structure is very common 
in some BASICs, as user-definable procedures and functions are compara- 
tively rare. The keywords needed for a subroutine are GOSUB and 
RETURN. They are used in much the same way as DEF, PROC and 
ENDPROC above; to go to a subroutine you use a GOSUB statement and to 
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leave the routine you end it with RETURN. Unlike the structures already 
described they cannot be given a name and are referenced by the line 
number of the code. This makes them slightly more difficult to debug and test, 
and moving them to a different program location means changing all the lines 
that call them so that they point to the new line number. There can be as 
many RETURNs as you desire in a subroutine but they should be conditional 
upon some test if you use more than one. What is different from the structures 
described above is that subroutines cannot have parameters, nor can they 
return values to a variable. This means that, for most purposes, when writing 
In BBC BASIC you can write more effective code using procedures and 
functions than by using subroutines. They cannot keep their variables 
LOCAL either. 

There is one notable area in which you can use subroutines but not 
procedures or functions. If you wish to test a variable for a range of values and 
then take appropriate action depending on the result of the test you have to 
write a whole series of IF/‘THEN statements in order to use procedures. Using 
subroutines you can use the ON GOSUB structure. This means that there is 
only one test to be made for the program to respond to a whole range of 
possible values. There is a good example of code where this might have been 
used in the program ‘Humber’ (Chapter 2). DEF PROCmove_hex has a 
series of tests on lines 1380 to 1430, each of which tests the same variable for 
a different value. If the various ‘move’ procedures had been written as 
subroutines and arranged so that we input numerical values for the desired 
direction, then this series of lines could have been written as follows: 


Figure 4.6 
138@ ON dirt’ GOSUB 1526, 1560, 1600, 1634, 
14578, 171@ 


Lines 1390 to 1430 could then have been deleted completely. 

Why, you: may ask, didn’t you write it that way in the first place? The 
answer lies in style, habit and speed. Consider speed first: using a GOSUB 
causes the BASIC interpreter to start, at the beginning of the program, to try 
to find the line number which we have decided to jump to. It does this every 
time it has to GOSUB anywhere. It doesn’t keep a register of all the GOSUBs 
and their locations in memory. It does keep such a register for procedures and 
functions; whenever a new one is called, its name and memory location are 
entered into the register, so that next time it is used the interpreter can jump 
straight to that code and not bother looking through memory to find it again. 
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So, after the first call to a procedure, these calls are executed much faster due 
to the searching involved in finding a GOSUB location not being required. 
This type of consideration is very important in long programs. With regard to 
style and habit, they are beyond explanation usually. We all have our little 
foibles and differences and sometimes these make it easier to structure a 
program in one way than in another which might actually be more logical. 
Feel free to try to restructure ‘Humber’ to use ON GOSUB if you would like 
the experience. 

There is a very similar structure available that doesn’t return to the point 
where it was called from at all. This is the ON GOTO structure and is very 
neglected in its use, probably because many advocates of structured 
programming believe that the GOTO statement is totally unnecessary. There 
is even a rumour that one expert had a special BBC BASIC chip blown so 
that, if anyone wrote a program with a GOTO statement in it, when the 
program was RUN a ‘Syntax Error’ message was displayed. How true or 
likely this is we don’t know; if you search carefully you will find a few GOTOs 
in this book. What we should try to avoid is the ‘unconditional’ GOTO. This 
might be used where we missed out some code or had a second thought after 
the main part of the program was written, but it displays a lack of 
understanding of the program structure and should be avoided at all costs. 

Using ON GOTO is necessary only when the program needs to divide into 
several sections and never come back to the same point again. If there was a 
need to rejoin a main program flow then you would be much better placed to 
use the ON GOSUB structure. As with ON GOSUB, the program follows one 
of the line numbers given dependent upon the value of the variable tested. 

The conditional branch is another feature of BASIC which can be used in a 
structured programming approach. The need to move to another program 
line or procedure is tested and the branch is followed only IF a certain 
condition is fulfilled. The BASIC keywords that offer such a structure are IF, 
THEN and ELSE. Once again it is only recently that BASICs have had the 
ability to follow an ELSE condition but it is a very useful option. You are no 
doubt aware of the use of these keywords, so a little mention of their merits 
should be all that is required here. Unlike the ON keyword, using IF, THEN 
and ELSE means that we can branch to procedures and functions, although 
we have only the option of two available. 

At the end of the branch, whether following the THEN or the ELSE route, 
program execution is passed back to the statement following the last one 
called. With multi-statement lines this means that we can avoid the need to 
test the same condition on several adjacent lines and can have execution 
follow quite a number of separate statements before returning to the main 
program spine. The logic of the condition is that if the evaluation of the 
statement following the IF is TRUE, in logical terms, execution follows the 
THEN branch; if it is evaluated FALSE, then the ELSE branch is followed. It is 
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perfectly possible not to use the ELSE following a THEN, in which case 
program execution follows from the next program line whether the IF branch 
has been followed or not. The THEN keyword can also be omitted, as the 
very use of the keyword IF suggests that a THEN must follow. This means 
that lines such as these are all valid and equivalent: 


Figure 4.7 | 
38@ IF happy=TRUE THEN (PROCSmi le 


and 
3830 IF happy=TRUE PROCsmile 
ana 


360 [IF happy FROCsmile. 


Finally there are two looping structures available in BBC BASIC. The first, 
and probably most familiar, is the FOR/NEXT loop. Loops. are a way of 
making something happen more than once without having to waste memory 
space with extra code. There is a good example of an apt use of a loop above 
when we were talking about parameter passing. The feature of a FOR/NEXT 
loop which distinguishes it from others is that it uses a counter, the index 
variable, to decide how many times it will execute the code. This variable can 
itself be used, within the loop, in a similar way to a normal variable; i.e. it can 
be printed on screen, used to index an array and even be assigned a new 
value. This is most useful where an element of numerical structure is needed, 
for example when you are entering the elements of an array or printing out 
lines on a screen. 

When a FOR/NEXT loop is started there are two values, or parameters, 
that need to be given: the initial value and the limiting value. These are the 
first and last values for which the code enclosed by the FOR and the NEXT 
will be executed. It is also possible to set the STEP size, i.e. how much up or 
down the variable is to be changed each time the NEXT is reached, but this is 
optional and if not specified will be set to 1. By specifying these values in what 
might be regarded as reverse order, and setting a negative step size, it is also 
possible to ‘count down’ using this loop. This can be very useful when 
moving characters around the screen in games, etc. What the interpreter does 
is set the variable being used as the index to the first value given and then 
execute the code until the NEXT is found. The index value is then altered by 
one STEP, i.e. becomes either one step larger or smaller depending on the 
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sign of the step specified. This new value is then compared with the limiting 
value and if it is still within the limit, or equal to it, the code is executed once 
more. Only when the index is outside the limiting value does execution of the 
code cease and control is passed to the next statement. 

This explanation may help us to understand certain features of a 
FOR/NEXT loop which we need to know in order to use them effectively. 
Firstly a FOR/NEXT loop is always executed at least once; this is because the 
test against the limit isn’t made until the NEXT is reached. Even if the initial 
value is 1 and the limit is 0 the loop will still be executed once. If you want to 
prevent this, perform a test before the FOR statement and branch around the 
loop if necessary. 

Another feature of the loop is that on exit from this code the index variable 
is always bigger than the limiting value by one step. You must subtract one 
step if you wish to use this value later in the program; perhaps it would be 
better to use the limiting value itself, rather than go to all this trouble. 

FOR/NEXT loops can be nested to a certain depth. You can have one loop 
starting inside another but on condition that the loops don’t cross over at all. 
One loop must be completely contained inside the other and you must never 
jump out of a loop. This type of structure might be useful if you want to move 
something in two directions on screen, or to manipulate a two-dimensional 
array, but the rules must be rigorously followed or chaos will ensue. An 
interesting feature of BBC BASIC makes these nested loops faster than one 
might expect. When you write a line with a NEXT statement the syntax rules 
say that there should be a variable name following, the loop index name. 
However, in BBC BASIC this name is optional and if omitted it speeds up 
execution of the program! The reason is that the interpreter assumes that you 
want to go back to the last loop you started and doesn’t bother to check 
through its list of variable names completely. So although it is bad 
programming syntax to leave the variable name off such a statement, it can 
be justified on speed terms; for maximum readability, we recommend using 
the name. 

Finally, although it is possible to set the index value to be equal to or higher 
than the limit value, whilst in the loop, to ensure that it ceases execution for 
some reason, it is not advisable. This is especially so since there is another 
loop structure that can cope with this in a much more elegant manner. 

This is the REPEAT/UNTIL loop which unlike the earlier one doesn’t have 
any numerical parameters. This loop as its name suggests carries out a 
particular section of code until a certain condition, or set of conditions, is 
fulfilled. This is most useful where an exact number of executions of the code 
is not necessary but where you have to be sure that something has changed 
whilst in the loop. We use a loop like this to slow programs down a little, by 
deciding how long we want to wait in centiseconds and then repeatedly 
testing the internal ‘clock’ TIME to see if it has gone beyond our limit — in 
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which case we jump out of the loop. It could also be used to wait for a certain 
key to be pressed, etc. 

If you want to exit a loop if a condition is met, but you want to set up a 
counter too, use the REPEAT/UNTIL structure by setting the counter to the 
Initial value before you enter the loop and then altering its value inside it. 
Then, when the condition is met, exit the loop and use the counter for 
whatever purpose it was set up. This is the way to avoid having to set index 
values within FOR/NEXT loops. There is another type of loop which isn’t 
Included in BBC BASIC. This is the WHILE/WEND loop which is the only 
one of the three that doesn’t always execute once. This is because the 
conditional test is performed before entering the loop rather than at the end of 
the first execution. If we want to simulate this in BBC BASIC we must perform 
a test before we enter the loop and branch around if the condition is met. 

The keywords explained here are the main features of BBC BASIC that 
make structured programming so easy. So that you have plenty of experience 
with these structures, before trying to use them yourself, we recommend that 
you read through and type into your computer the series of program modules 
that follow in the next chapters. They should provide a grounding in how 
structure makes the writing of programs, especially in education, faster and 
easier. 


Modules for Program Development 


In this chapter we introduce some of the modules that we have developed to 
make writing programs, especially educational ones, a little more simple and 
easy. There are a number of program listings in this, and in all the following 
chapters. Before you start to type them into your machine we recommend 
that you read Appendix 3, which has full information about the style of the 
listings and hints on how to type them into your machine and then store them 
on cassette or disk. We think that you will make fewer errors, and therefore 
spend less time debugging, after reading it. Take special notice of the section 
on spooling files, as that is the most important informantion related to the 
listings in this chapter. 

We have already recommended a modular approach to programming. 
Here we provide you with some modules that we have found useful whilst 
developing programs for educational purposes. They cover a whole range of 
activities, but for the sake of a structured presentation we have divided them 
into three groups. The first of these are the ‘output modules’ and these are 
contained in this chapter. They cover output of all types, not simply to a 
printer but also those modules which help output and presentation to the 
screen as well. The complete range of output using the BBC and Electron 
covers colour, graphics and sound, so there are procedures and functions to 
cover this whole area. 
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The second set of modules deal with the opposite end of the computer’s 
activities: input. In Chapter 6 these are listed and documented; they are, in 
our opinion, the most useful routines in educational work. In the same 
chapter there are the modules that can only be grouped under the title 
‘miscellaneous’, covering whatever cannot be put into the other two 
categories. 

So that you may be able to both use these modules and understand their 
working we have given a very full explanation of each one as it is presented. 
This doesn’t mean you must read and thoroughly understand each one 
before you start to use it. In fact we would prefer you to type in each module 
before reading, in detail, the documentation: as you read the information you 
will be able to check each of the ideas we suggest as it occurs in the text. This 
is probably the way to get the best out of this section and will reward your 
diligence enormously. 

The format for each module will follow this pattern: 


Module title and the procedures and functions that this involves. 

A brief description of the aims and purpose of the module. 

The program listings and their associated documentation. 

Simple testing suggestions, used to prove that the module is working 
correctly and that your typing is accurate. 

5 Suggestions for use within an educational program. 


Bm WN = 


After typing these modules into your computer we will demonstrate their use 
with a few short yet effective educational programs. 7 

To help you keep these modules in a ‘library’ for use in your own programs 
they have been numbered in a rather special way. All the modules have line 
numbers of 10000 and above. The reason behind this is that you can write 
your own code from line number 0 to line number 9999. We cannot believe 
that you will want to write more than 10,000 lines of BASIC and even if you 
stick to line numbers incremented in tens you have 1000 lines to spare. Each 
module starts at a line number which is a multiple of 500 and every module 
has its own line number range. You are unlikely to have clashes of line 
number when using more than one of these modules. This does involve a 
certain discipline on your part, though, especially with regard to using AUTO 
and RENUMBER. Avoid RENUMBER if at all possible when writing your own 
programs using the modules. This is because it will also renumber the 
modules and then you won’t know where to find them again if you want to 
make a slight alteration. Using AUTO is fine but remember to use the starting 
line number of the module that you are to type in. If you insist on typing these 
modules at other line numbers then you will have to sort out for yourself the 
line numbers that the various GOTOs GOSUBs and RESTORES reference. 
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Module 1__ Printer checking 
FNprinteron. Lines 10000 to 10080. 


This is a useful function to test if a printer is attached and working. If you allow 
a user to select a printout routine without using a procedure like this then you 
can cause the machine to ‘hang up’ when its printer buffer becomes full. 
There is no way out of this situation except by pressing BREAK which means 
that you have lost all your variables, probably what you wanted to print! The 
function returns a value of TRUE (—1) if the printer is working correctly and 
FALSE (0) if it isn’t. It cannot tell you exactly what is wrong but if FALSE is 
returned then you can be certain that sending output to the printer will cause 
problems, so use the function to test before you do. 


Figure 5.1 

16606 DEFFNprinteron 

19010 *FX15,3 

10620 VDU2Z,13,13,13,3 
12030 AL=&98 

10040 X%=3 

100350 Y2=6 

16060 '&76=USR (&FFFA4) 
10070 *FX15,3 

1008@ =-(7%73 AND 1) 


This routine relies upon the fact that if a printer is switched on then 
anything placed in the BBC’s printer buffer will be sent to it after a line feed 
code is sent. If a printer is not switched on then anything put into the buffer 
will stay there until we test for it. Lines 10010 and 10070 flush the printer 
buffer to ensure that it is completely empty before we put anything into it. The 
second occurrence clears it after this function is complete. The VDU line turns 
the printer on and then puts three line feeds (VDU 13) into the buffer before 
switching the printer off again (VDU 2 = printer on; VDU 3 = printer off). The 
next lines are setting up variables ready to call the operating system (using 
OSBYTE) to check the state of the printer buffer. If there is anything in this 
buffer, the operating system will return a value of 1 in its C flag; if not, this flag 
will be 0. Line 10080 converts the two possible values into —1 for TRUE, i.e. 
the buffer is empty so the printer is turned on; or 0 for FALSE, i.e. there is 
something in the buffer so the printer cannot be working properly. We are at a 
loss to explain why we need to put more than one line feed (VDU 13) into the 
buffer, but all the BBC experts we have checked with have had the same 
results! 
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Test this by typing the following line in command mode: 


PRINT FNprinteron 


If your printer is switched on, —1 will be printed; if not, the value O will appear. 
If you do have a printer, type this line four times with the printer in the 
following states: 


(a) Switched off at the mains. 

(b) Switched on but with the ready light off. 

(c) Switched on and ready light on. 

(d) Switched on and ready light on but lead to the computer 
disconnected. 


Only when the printer is in state (c) should you get the value —1 printed on 
screen. 

Use this every time the program is about to send output to a printer; if 
FALSE, either branch around the code or print out an error message on 
screen. This module is used in the ‘times table’ program and a number of the 
others that follow. 


Module 2 Text centring 


PROCcentre. Lines 11000 to 11020. 
PROCacentre. Lines 11030 to 11130. 
PROCtcentre. Lines 11140 to 11190. 


It is attractive to have text centred on the screen when printing instructions or 
details. This module centres text in any mode and with text of any length up 
to the number of characters per line allowable, in that mode, but never more 
than this length. The parameters are, respectively: the line or row of text you 
wish to print upon (row%); and the text you wish to print, which can be any 
mixture of literal strings or string variables (text$). You can also specify the 
colour. This is useful only in those modes where there is more than one 
available, but must always be included nevertheless (colour%). In two-colour 
modes this should always be set to 1, unless you like invisible text! 


Figure 5.2 

11600 DEFFROCcentre (row%,text#,colour%) 

11010 IF 7&361=0 PROCtcentre ELSE 
PROCgcentre 

11026 ENDPROC 
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11030 DEFFROCgcentre 

114948 LOCALX<4,yA,moxr 

1:658@ [F ?&256=0 THEN mo4#=7&34F ELSE 
MOA=PRS4F RS 

11460 «2=646-— (LEN itext?) #moZ4)-1 

11070 y42=1023-—(rowL#s23} 

11680 VbDUS 

11698 GCOL@,colour’Z 

111G0@ MOVEx4~,y% 

111140 PRINTtext? 

11:28 VDU4 

11130 ENDPROC 


i1114@ DEFFROCtcentre 

1115@ LOCAL ch2z 

11166 IF F&356=1 ch4=40 ELSE ch“~z=26 

11176 COLOURcolour dA 

1118@ PRINT TAB(chH~-LEN (text)? /2,row2Z) 5 
text? 

11197@ ENDFROC 


The first of these procedures simply decides which of the other two to use 
whenever it is called. The reason for this is that in a graphic mode it is possible 
to centre text exactly using the graphics cursor, which means that text with an 
odd number of letters is still centred; in non-graphic modes this is not 
possible. The test on line 11010 checks one byte of the operating system 
workspace, the one which holds the nature of the mode the machine 
is currently in. This location is O if it is a text mode — execution passes 
to PROCtcentre and non-zero otherwise — so execution passes to 
PROCacentre. 

PROCgcentre uses two more of the operating system workspace locations 
to find out how many graphic units there are to a single pixel location. Then 
using this information on line 11060 the x co-ordinate of the MOVE is 
calculated. There are always 32 graphic units to each row of text, in graphic 
modes, and so it is easy to calculate the y co-ordinate from the parameter 
used to call the procedure (row%). The VDU 5 joins the text and graphic 
cursors ready to MOVE to the correct location. Line 11090 changes the 
graphics colour to the parameter value of colour%. Then the text is printed 
and the cursors separated before we cease execution of this procedure. 

PROCtcentre is simpler than that for graphics as there is less calculation to 
do. On line 11160 another workspace location is ‘peeked’ to see how many 
characters there are on a row, if it holds the value ‘1’ there are 80 so we set 
ch% to 40, i.e. the centre of the screen. If it has another value we presume we 
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are in mode 6 and set the centre of the screen to be 20 instead. All we need to 
do now is to divide the length of the text by two, take this away from the value 
for the centre of the screen and we know what the correct TAB value should 
be. Line 11180 performs this task and prints the text in the nearest possible 
approximation to the centre of the screen. 

To test this module you need to type the following command seven times 
because you should try every screen mode. So type a mode command and 
then the following: 


PROCcentre(10,“‘This is a test”, 1) 


Using the ‘1’ as the last parameter ensures that the colour used to print the 
text, in those modes which allow more than two, will not be white. 


Module 3_ Text underlining 
PROCunderline. Lines 11500 to 11620. 


Another attractive way of displaying text is to have it underlined (yet it is quite 
difficult to achieve simply). This module takes a piece of text and the location 
and colour information as parameters and attempts to print it on screen 
underlined in the colour you desire. The reason for saying ‘attempts’ is that 
this is not possible in text-only modes, as it uses the graphic cursor and colour 
commands. 1 


Figure 5.3 


1150@ DEF PROCunderline (text3,colZ, 
rows, colours) 

115186 LOCAL x4%,y4,mo~z 

11520 IF ?7?&3461 = @ PRINT “Not graphic 
mode" =: ENDPROC 

115380 VDU Ss 

11540 IF 72356 = @ THEN moZ = ?&S4F #2 
ELSE moZ = ?&34F#4 

11550 x“ = col“z*moz—-1 

11560 yA = 18023-(rowZ*32) 

11570 VDU S 

11580 MOVE x%,yAZ: PRINT texts; 

11590 GCOL 3,colourz 

11600 MOVE x%,y4-1@:FPRINT STRINGS 
(LEN(text#) , CHRS95) 

11610 VDU 4 

11620 ENDPROC 
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The parameters of this procedure are reasonably obvious; they are: the text 
to be printed (text$), the column to start printing in (col%), the row to print on 
(row%) and the colour of the underline (colour%). The text is printed in the 
currently set colour; it is only the underlining colour that is set as a parameter 
here. The test used on line 11520 will become familiar as you type the other 
modules that we provide. It uses the operating system workspace byte, which 
indicates whether we are in a graphic mode, to abort if we are in a 
non-graphic mode. This is of no real use when a program is finished but by 
including it in the original it prevents errors during program development. If 
we are in a graphic mode, the locations which hold the pixel size are checked 
again to calculate the x co-ordinate value so that we can MOVE to the 
selected column. The y co-ordinate is calculated as in the previous module 
and then the cursors are joined, the MOVE is made and the text printed. The 
colour of the underline is then set and the cursor moved back to the start of 
the line of text again. The ‘— 10’ ensures that the underline doesn’t touch any 
of the characters printed. Notice that the GCOL is followed by a 3 instead of 
the more usual 0. This is to prevent the overwriting of the text by the 
underline. The 3 means that whatever we are printing is to be EOR’ed, 
‘Exclusive OR’ed’ on the screen; in this case all that does is allow us to write 
one character over another without destroying the original. The CHR$95 is 
the underline character, which you can find on the keyboard under the °* 
sign. The cursors are then separated by the VDU 4 and execution is 
completed. It would be possible to perform this task usinga DRAW command 
to underline but we preferred the above method. 

To test this module you need to select all the screen modes again and 
follow that command with this line: 


PROCunderline(“Testing — Testing’, 1,10,1) 


This should cause the procedure to stop with an error message if you are in 
mode 6 or 3 but should have the expected effect in the other modes. In 
modes other than those with two colours there should be a colour change in 
the underline too. 

We would especially recommend this module for titles and instructions 
where emphasis is required. There is no reason why in certain modes you 
couldn’t underline with a flashing colour, those numbered 8 to 15, for a really 
FLASHY display. 


Module 4 Cursor control 


PROCcoff. Line 12000. 
PROCcon. Line 12010. 


There is no doubt that the cursor can be a distraction when you are drawing 
on the screen or at almost any other time too. Therefore the ability to turn it 
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off and on again at will is very desirable, which is what this procedure is all 
about. 


Figure 5.4 


1200@ DEFPROCcoff : VDU23;&200A;0;0;@;: 
ENDPROC 


12010 DEFPROCcon : VDU23;&670A;0:0;0;: 
ENDPROC 


There are a number of ways to turn the cursor off and on but using the 
code here we can get results on all the versions of the BBC operating system 
issues and on the Electron too. What needs to be altered is one of the registers 
that displays the cursor and this is what occurs when this code is executed. 
The only time when this doesn’t work correctly is in mode 7 on the BBC. To 
use, you simply type PROCcoff to make it disappear and PROCcon when 
you require its presence again. Changing the screen mode and joining or 
separating the cursors can make it reappear at unexpected moments. 

To test this in all modes, first select the mode as before and then type: 


PROCcoff 
then: 
PROCcon 


for each mode. If you are using the BBC you should see an interesting change 
in mode 7. 

Although the cursor can be distracting at times, it can have its uses. We 
particularly favour its use to remind people that there is some answer 
expected from them. We therefore tend to use PROCcon just before a line, 
procedure or function that requires a response from the user. Usually this 
means that after the input has been checked and accepted we have to call 
PROCcoff to-get rid of it again. 


Module 5 Double-height characters 
PROCdouble. Lines 13000 to 13130. 


Whilst there is an enormous variety of screen modes available on these 
computers, all with differing heights, widths and styles of text, you can gain 
greater impact by having more than one style and size on the screen at once. 
This module allows the use of text which is twice as high as normal for the 
particular screen mode currently used. 
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Figure 5.5 

13600 DEF PROCdouble (string?) 

1301@ LOCAL chart,define,loopz, 

vposZ ,posi4,0QSWORD 

1306206 vposZ%=VFOS =: pos4z=F05 

13420 AZ=RA: XZ4=6: YZ=&A: OSWORD=2FFF1 

12040 define=zAGQ 

13650 FOR loopz=1 TO LEN(string?) 

12066 char #=M1D4 (string?#,loopz,1i) 

13970 def ine=ASC (char) 

13086 CALL OSWORD 

13090 VDU2S ,240,define?7l ,define?l, 
define?2 define?2 define’s, 
define?s, define?4 definev4 

13100 VDU23,241,define?s,detine7s, 
define?é,define?’é4,define??7, 
define??7 ,define?8,definevs 

12110 PRINT TAB (pos2Z+loop2~,vpos2) 5 
CHR (240) 3 TAB (poscét+loopsZ, 
vpos4ét+1) ; CHR (241) 

13120 NEXT loop2Z 

12130 ENDPROC 


The working of this routine is dependent upon one of the machine 
operating system commands, OSWORD. The command can be used to 
perform many tasks; in this case we use it to find out what the ‘bit pattern’ of a 
particular character is. This is the pattern which determines what a character 
will look like on the screen. Using this pattern we define two new characters, 
on lines 13090 and 13100, to be that pattern but double the height. These 
special characters can then be used to print out the text given as the 
parameter ‘string$’. Line 13020 sets variables to our current screen location 
ready for printing the text; it is therefore essential that you have the cursor in 
the correct position before you call this procedure. This can be done using a 
simple PRINT TAB structure. 

Lines 13030 and 13040 set all the variables needed by the operating 
system call. A%=&A is the type of action we require, i.e. getting the bit 
pattern for the character we are about to print. The loop is then executed for 
every character in the string parameter, line 13060 finding the actual 
character. The next line finds its ASCII number ready for the call to the 
operating system on line 13080. By ‘peeking’ the values that the operating 
system returns into memory location ‘define’ we can define our two 
double-height characters on lines 13090 and 13100. To print these in the 
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correct position we use the printing code on line 13110. This prints the 
second character under the first using the loop index to move along the 
screen by one each time. When this has been done for one character we 
return to the beginning of the loop and try to print the next one. If the whole 
string has been printed, execution terminates. 

Testing this routine can be done in any mode you choose, so why not try 
them all and notice the different effects? Typing 


PROCdouble(“ «What a test!!««’’) 


should work in all of them. However, the module doesn’t check to see if you 
are going on to a new screen line, and will give unusual results if you do! 
User-defined character numbers 240 and 241 are employed by this module; 
if you have already defined these the definitions will be overwritten. If this is a 
problem, the numbers used in this procedure can be changed to any that you 
prefer. 

The use of this module is unbounded. We use it a great deal in our displays. 
It can be utilized to get double-size invaders, pacmen or any user-defined 
character. You need to have defined your character first, of course, but then it 
can be given as the parameter using CHR$(character number). Some of the 
symbols on the keyboard can make attractive borders and decoration in 
double height, too. 


Module 6 Double-height and -width characters 


PROCquadruple. Lines 13500 to 13680. 
PROCtest. Lines 13690 to 13740. 
FNtest. Lines 13750 to 13810. 


Whilst the double-height characters produced by the module above are very 
attractive in modes 2 and 5, they can look a little out of proportion in some of 
the other modes. This module gives us the ability to produce text which is in 
exactly the same proportions as the ncrmal size but twice as wide and twice as 
high. When all three types are on screen together the effect is most attractive. 


Figure 5.6 


13500 DEF PROCquadruple (string?) 
1351@ LOCAL char#,define,ioopZ, 
vposZ,pos2Z,Q0SWORD, 
chari,char2 
13520 vpos4=VFOS =: pos%z=F0S 
12530 AZ=&2A: XZ=8: YAZ=2A: OSWORD=2ZFFF1 
12540 define=%AQG: char 1=%A10: char 2=2%AL0 
13550 FOR] oop“~=@TOLEN (string?)-1 
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15560 char s=MI1ID$ (strings, loopZét+i1,1) 

12570 ?define=ASC (char?) 

13580 CALL OSWORD 

125908 FORLineZ=1 TOS 

12606 FROCtest (define?lineZ) 

1361@ NEXT 

134626 VDU2S,241,chariv?i,chari?i, 
chari?2,chari?2,chari?s3, 
char1?2,chari?4,chari?4 

134630 VDU2S3 ,243,chari1?5,chari?s, 
char 176,chari?é,chari?/7, 
char1?7,chari?8s,chari?é 

13642 VDU2S ,242,char2?71,char27l, 
char272,char2?72,char2?73, 
char2?3,char2?4,char274 

134630 YDU2S , 244, char 275,char275, 
char276,char276,char2?77, 
char2?77,char278,char2?78 

13660 FRINTTAB (posZ+1 00p4Z#2,vposs) 5 


CHRS2415 CHRS242: TAB (CpaosAt 
loop4%#2 , vpos4+1) sCHRS243; 
CHR#244 

13676 NEXT 

12680 ENDFROC 


The same basic method is used as above in PROCdouble but in this case 
we have to make each character spread across two characters horizontally as 
well as two vertically. This means that there are some mathematics involved, 
firstly to get at the part of the original character definition that we need at each 
stage, and secondly to make the new character have the right value. The only 
parameter is the text to be printed in the new style (string$). The lines from 
13510 to 13580 are almost identical to those in PROCdouble, the only 
change being on line 13540 where we specify two other memory locations, 
needed for the extra characters involved. Lines 13590 to 13610 comprise the 
loop which calls the mathematics routine for each part of the character. This 
routine is detailed below. The next lines define four characters to be the new, 
bigger shape, and this is printed in the correct position by line 13660. 


Figure 5.7 

13690 DEFPROCtest (byteZ) 

13700 hixt=byteZ% AND &FO@shix“z=hiz DIV &18 
13710 lot#=byte% AND &F 
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13720 chariv?ilinesz=FNtest (hid) 
13730 char2?7line“Z=FNtest (10%) 
3740 ENDPROC 


13750 DEFFNtest (nibble?) 
12766 value= 
127780 IF (nibbleZ AND 1) 
value“Z=valuedats 
1378@ IF (nibble% AND 2) 
value“Z=valueAt+i2 
13790 IF (nibbleZ AND 4) 
valuetZ=valueszt+48 
13800 IF (nibbleZ AND 8) 
value“z=valuesz+192 
13818 =valueZs 


These routines do the conversion from the old value for each line of the 
character to the new values ready for the character definition. The first action 
is the splitting of each value into two ‘nibbles’, each requiring different 
characters. Execution is then passed to the function which changes the old 
value into the one required; this involves making each dot in the old character 
two dots wide and moving everything along to the left to make it fit in. All that 
we have done is set up a conversion table that tests each dot and, if it is set, 
j.e. would appear white on the screen, we have added on the correct value to 
get it to cover the correct two new dots. This has to be done eight times for 
each character and is therefore a little slow. When the conversion is complete 
the value is left in memory to be ‘peeked’ out by the character-defining lines 
in the procedure above. 

Once again this can be tested in all the modes available, so here is a short 
program to test it for you. Type this in using AUTO whilst the module is still in 
memory, but after you have saved it as described in Appendix 3. 


Figure 5.8 

16 FOR mode = @ TO 6 

20 MODE mode 

30 PROCquadruple("Testing") 
40 a=GET 

9@ NEXT mode 

60 END 
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This program will cycle through the modes, waiting for you to press a key 
before going to the next one. It is important once again not to supply more 
letters than will fit on to the screen, or the result will be less than attractive. 
(You could use a similar program with those procedures above which require 
testing in different modes. ) 

All the suggestions above can be applied to this procedure too. The only 
real drawback is that it is slow due to the amount of maths involved to 
organize the right shapes. The routine uses characters 240 to 243, so if they 
are needed elsewhere in a program these values will need to be changed. 


Module 7 Text and graphic windows 


Lines 14000 to 14110. 
Lines 14500 to 14570. 


PROCgwindow. 
PROCtwindow. 


The facility to specify two types of window on the BBC screen is most useful 
for making attractive displays, but it isn’t very ‘user friendly’. This module can 
help you out of the calculations required by setting up windows using the 


computer to do the difficult bits! 


Figure 5.9 


14600 


140104 
14026 


14630 


140640 
1440506 
140506 
14407@ 
14080 
14090 
14100 
14118 


DEFPROCgwindow(colZ%,row2Z, 
lenz, depth’, colours} 

LOCAL xloZ, yloz, xhiz, yhidZ, 
IF 7&361=0 PRINT"Not graphic 
mode" :ENDFROC 

IF ?&2356=0 THEN mo4=7&34F #2 
FLSE mo4=7234F #4 

xlo“Z=col %~¥m0% 
xhi“Z=ClenZz+colZ)*#mo“z —1 
ylo4=1024-(rowZ+depthZ) #32 
yhi 4Z=1023-— (row%*32) 

VDUS4 ,xloAsyloAsxhics yhics 
GCOL@,col ourZ+128 

CLG 

ENDPROC 


mo“ 


This procedure sets up the graphics window to your specification. There 
are several parameters to be specified. The first two are the x and y values of 
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the position that you want to start the window, the col% being the value of the 
left edge of the window and the row% being the top edge location. All these 
parameters use character locations, not graphic locations. We feel that this is 
the easier way to set these up. The next two parameters are the length, or 
width, of the window to be set (len%) and the depth of it down the screen 
(width%). Finally we need to know what colour to clear the window to and so 
this is specified (colour%). 

There is the usual test to see if the mode is a graphic one before we work 
out how many graphic units per pixel. Both of these lines, 14020 and 14030, 
use the operating system workspace to get the information. If it were not done 
in this manner then you would have to tell the module what mode you are in 
too! The next four lines set variables to be the bottom x and y co-ordinates 
and the top x and y values, this time in graphic units. Line 14080 sets up the 
window, and the next two lines clear it to the colour specified. The only 
complex part is the mathematics, which are explained in detail in earlier 
procedures. 


Figure 5.10 


14500 DEFPROCtwindow(col%,row4,lenz, 
depth~Z,colour 2) 

14510 LOCALxhiz4z,yhiz 

14520 «xhiA=col At+lenZs—-i 

1453@ ylo“=row4+depthZ-1 

143544 VDUZS,colZ,ylo“~,xhi,rows 

14535@ COLOURCcCOI] ourZ+128 

1436@ CLS 

1457@ ENDPROC 


This procedure takes exactly the same parameters but sets up a text 
window instead. The calculations are much simpler than for the graphics 
window and as this works in all modes there is no need for that check. The 
window is set up on line 14540 and cleared on the following lines. One vital 
difference between the two that needs to be understood is that the graphics 
window can be set up without disturbing the text cursor, whereas the text 
window always places the text cursor at the first location within the new 
window. There are further details about windows in the machine manuals. 

To test this module there is another short program. 
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Figure 5.11 

16 FOR mode = 6 TQ & 

28 MODE. mode 

mS") PROCgwindow (5,5,0,4,1) 
4a PRINT "Hello" 

3@ PFROCtwindow(15,15,5,5,1) 
66 COLOUR @ 

7@ PRINT “Hello” 

86 a=GET 

7a NEXT mode 

1494 END 


There will be two error messages in modes 3 and 6 but in the others you 
should be able to see the windows build and clear in an appropriate way. The 
colours will change depending on how many are allowed in a particular 
mode. 

This module has obvious uses in keeping text within certain areas or 
protecting graphics already drawn from new ones, but there are other uses 
too. A major one is to clear the screen of unwanted displays. This is very 
simple with this module and you will find it extensively used in the 
demonstration programs. Another use is plotting four-sided shapes in 
pictures, etc.; the method is much faster than the more usual triangle plotting 
described in the manuals. Also, by setting up several windows all with slightly 
smaller and more central co-ordinates, the screen can be given an attractive 
border. 


Module 8 Shape drawing 


PROCcircle. Lines 15000 to 15130. 
PROCpoly. Lines 15500 to 15620. 


Drawing circles is not one of the options in BBC BASIC, which is a sad 
omission. This module contains two routines that allow you to draw a shape 
with any number of sides from three to infinity. If you are using only circles in 
your program, use PROCcircle. If you are going to draw a number of shapes 
each with a different number of sides, use PROCpoly and specify a number of 
sides over twenty-five; this will provide you with acceptable circles too. 
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igure 5.12 


(S@Q00 DEF PROCcircle(xpos%,ypos/7Z, 
radiusZ,fi11%) 
15010 LOCAL new_xposZ4,new_ypos/,steps~/, 
accuracy > 
15020 IF 7&361=@ PRINT"Not graphic 
mode": ENDPROC 
I503@ steps=25 =: accuracy=2*PI/steps 
13040 MOVE xposAtradius2z,yposa 
(5050 angle=@ 
1°@606 REPEAT 
150708 angle=angletaccuracy 
1508@ new _xpos4=xposAtradiusZz 
xCOS angle 
(30990 new_ypos4Z=yposAZ+r adiusZ 
*SIN angle 
13100 IF £1112 THEN DRAW xpos~Z,yposad: 
PLOT 85,new_xposZ,new_yposz 
ELSE DRAW new_xpos%,new_yposaé 
15110 UNTIL angle?>+2*PI—-—accuracy 
1512@ IF 111% THEN PLOT 4&5, 
xposAtradiuszé, ypos2z 
ELSE DRAW xposétradiussz, yposa, 
151230 ENDFROC , 


The first two parameters supplied to this routine (xpos% and ypos%) set 
the centre of the circle to be drawn and are used in line 15040 along with the 
size parameter (radius%). The other parameter is a logical value for the type 
of circle to be plotted. If this is set to any non-zero value then the circle will be 
‘filled’. If this is a zero value the circle will be plotted in outline only. Both 
types are pfotted in the current graphics colour — if you want a new colour this 
must be set outside this routine. : 

There is no room to explain the mathematics here; sufficient to say that the 
maths don’t draw circles at all, but draw instead a large number of small 
triangles, or lines if in unfilled mode, which give the appearance of being a 
circle when joined. There is the now familiar test for graphics mode included 
for debugging purposes. 


80 
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Figure 5.13 


15500 


15510 


15520 
15538 
135546 
15556 
15568 
135570 


135600 
15610 


15620 


This is exactly the same procedure with just a simple extra parameter 
(sides%), which sets the number of steps to be taken around the 
circumference. We can select to draw polygons of any number of sides, three 
being a minimum in sensible values and twenty being a maximum before we 
start drawing circles. By giving a side% parameter of over twenty-five you are 
effectively using exactly the same procedure as the one above. This is the one 
to put in your programs if you want to draw shapes of different numbers of 
sides including circles. The only other change is the absence of the check for 


DEF PROCpoly (sides/Z,xpos“Z,yposz, 
radius“Z,fillZ) 
LOCAL new_xpos24,new -YPOs%, 
steps/£,accuracy 
accuracy=2*PI/sidesAz 
MOVE xpos4+tradiusZ,ypos2z 
angle=@ 
REPEAT 
angle=angletaccuracy 
new_xpos4=xposZtradiusaz 
*COS angle 
new_yposA=yposAtradiusZ 
#SIN angle 
IF £1112% THEN DRAW xpos2Z,yposcz: 
PLOT 85,new_xpos/Z,new_yposz 
ELSE DRAW new_xposZ,new_yposaz 
UNTIL angle?+2*PI—accuracy 
IF 111% THEN PLOT 85, 
xposAtradiusz, yposz 
ELSE DRAW xpos4+tradius2Z,yposz 
ENDPROC 


graphics mode. 


Testing these routines can be real fun and a little running demonstration 


program might look like this: 


Figure 5.14 


1@ MODE 2 
20 REPEAT 


30 
4Q 


GCOL @,RND(15) 
#i11=RND(2)-1 
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w@ xpos=RND (1279) 

460 ypos=RND (1023) 

78 radius=RND (600) 

80 Si des=RND (17)+2 

92 shape=RND(2)-1 

100 IF sides=15 CLS 

118 IF shape PROCpoly ‘(sides,xpos, 
ypos,radius,fill>) 
ELSE PROCcircle(xpos,ypos, 
radius,fill) 

120 UNTIL FALSE 

13@ END 


This uses the random number generator to set up all the parameters and 
then plots the shapes as specified. So that the screen does clear occasionally a 
‘sides’ value triggers the CLS. Notice that small circles or polygons distort 
quite badly due to the small numbers involved. If you want circles with small 
radii it would be better to set these up as user-defined characters. 

Once again the uses of these routines are many and various. Besides their 
main purpose, they can be employed to wipe the screen in an unusual way, 
everything disappearing in a clockwise direction. Plotting‘one shape inside 
another provides interesting patterns too. We feel certain that your 
imagination will suggest uses that we haven’t even contemplated! 


Module 9 Colour manipulation 


PROCcolourchange. Lines 16000 to 16020. 
PROCcolour. Lines 17000 to 17100. 


Colour is essential to most programs but learning the numerical values set for 
the colours isn’t easy. This module tries to simplify the use of colour by 
allowing you to type in the colour name instead of a number. 


Figure 5.15 


1600@ DEFPROCcol ourchange 
(logicalcolour</,newcolour’?Z) 

16018 VDU19,logicalcolour%, 
newcoloursz,@:G@; 

16020 ENDFROC 
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This part of the module is meant to make the BBC’s colour changing 
routine more ‘user friendly’. The parameters are the number of the logical 
colour that you want to change and the colour you want it changing to. 
Depending upon which mode you are in, the maximum value for logical 
colour can be 1, 3 or 15. The limit for the actual colour is always 15, but note 
that there is no error checking in the procedure itself. 


Figure 5.16 


1/060 
i/B1G 
17826 
1/7620 
17040 
17656 
i 7250 
17072 
170680 
1/7098 
17106 


DEF FROC colour 
BLACK =@ 
RED=1 
GREEN=2 
YELLOW= 
Biue=4 
MAGENTA=S 
CYAN=S& 
WHITE=7 
FLASH=& 
ENDPROC 


ca a 
— 


The technique used here is to create a type of pseudo-BASIC keyword 
holding the numerical value of a particular colour. All that is needed after 
these values are set — which might be done by the first call of an initialization 
routine — is to type the name of the colour required instead of its number. If 
you require a flashing colour then you should type, for example, ‘FLASH + 
RED’ and the colour will be set to red/blue flashing. This is best used for 
actual colour numbers as the logical colour values change from mode to 
mode whereas the colour numbers don’t. | 

To test this module, commands can be given straight from the keyboard, 
but here is a program to test it thoroughly: 


Figure 5.17 


1@ FROCcol our 

<@ MODE 

308 REPEAT 

40 CLS 

iB VDU2Z@ 

60 FORcol our=1TO3 
78 COLOUR colour 


HQ 


Modules for Program Development 83 


PRINTTAB(2@6,colour)s; 
“Colour "scolour 


70 NEXT 
100 
110 text#="Hello"” 
17Q FOR line=@ TO 20 
130 PRINTTAB(1@) ; 
140 FOR counter= 1 TO LEN(text#) 
10 COLOUR counter MOD 3+1 
1460 PRINTMID? (text#,counter ,1>) 3. 
170 NEXT 
18a FRINT 
19°@ NEXT 
.'4@ FOR counter= 1 T0 15 
“10 FOR colour= 1 7T0 3 
220 FROCcol ourchange 
(colour ,counter ) 
230 A=INKEY (300) 
240 NEXT 
200 NEXT 
260 VDBU2@ 
270 PROCcol ourchange (RED, BLUE) 
280 FORcolour=0TO1S 
290 PROCcol ourchange 
(BLACK ,colour ) 

300 A=INEKEY (300) 
310 NEXT 
320 VDUZO 
3@ PROCcol ourchange 

(2, FLASH+MAGENTA) 
548 COLOUR2 
350 PRINT"What a flash!!!" 
5460 COLOUR 3 
378 ,PRINT"Colour 3 is still WHITE” 
380 A=INKEY (300) 
390 UNTILFALSE 
400 END 


The first part of the program sets up a display using all three foreground 
colours that are available in this mode. Then PROCcolourchange is used, 
with numerical parameters, to cycle through all the available colours. The 
same is then done for the background colour, BLACK. Then the colours are 
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reset — VDU 20 does this — and then the background (BLACK) cycles through 
all the colours. The use of INKEY means that the program will pause for a 
while waiting for a key to be pressed. If you want to speed it up just keep your 
finger on a key. As you can see from the heavily indented listing there are a 
number of nested loops in this program. 

The use of this module is also dependent upon your imagination. You now 
have the flexibility to set colours using words or numbers. Using the words 
can increase the readability of listings dramatically but remember to initialize 
these variables at the very beginning of the program. 


Module 10 Moving graphic routines 


PROCmove_horizontal. Lines 18000 to 18230. 
PROCmove_vertical. Lines 18500 to 18730. 


Moving characters and shapes across a screen can be quite a complex task. 
These procedures, which are easily adapted to slightly different purposes as 
we will show later, provide a simple method of moving a string from one 
position to another. They use logical plotting routines and are as near to 
‘flicker free’ as it is possible to get in BASIC. 


Figure 5.18 


18600 DEF PROCmove_horizontal 
(old x4,new_xZ4,y_pos24,string?) 
18610 LOCAL position’Z,step~s,directionsz, 
step size%,delay~z~ 
18020 IF 7&361=@ PRINT"Not graphic 
mode": ENDPROC 
18430 step _s51ze4=32 
18@4@ VDU 5 ) 
18@5@ direction“Z=SGN (new_xZ-old_x%) 
18@60 step4=directiondé*step sizez 
18670 FOR positionZ=old_x% 
TO new_xZ-step% STEP step~Z% 
18a8a MOVE position%,y_pos% 
18a°70 GCOL 0,0 
131008 PRINT strings; 
18110 MOVE positiond¢t+stepZ,y_posz 
18120 GCOL @,1 
18136 PRINT strings; 
181408 delayZ=INKEY (5S) 
18130 NEXT position’ 
18160 MOVE positionZ,y_posAz 
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1817@ GCOL 0,0 

18180 PRINT string#; 
18190 MOVE new_x4%,y_posa 
18200 GCOL @,1 

18210 PRINT string#; 
18220 VDU 4 

18230 ENDPROC 


The first of these two routines moves strings from one position on the x axis 
to another; i.e. it will move things in a horizontal plane. There are several 
parameters to be supplied: the first two specify the old and new positions for 
the string (old_x% and new_x%); y_pos% is the y co-ordinate that you wish 
to move along, and string$ is the text or shape to be moved. After setting the 
local variables, the test for graphic mode is present. These routines will work 
only in graphic modes as they use the graphics cursor for positioning. Line 
18030 sets the amount of movement per step and has two effects on the 
movement. It firstly sets the amount of flicker you can expect to see (small 
steps mean less flicker), and at the same time it affects the speed of the 
movement (small steps taking longer). The value can be changed depending 
upon the screen mode that you want to use, but in all cases it is something of 
a compromise. 

The cursors are joined by the VDU 5 and then the direction of movement is 
calculated from the values given. If you want to move left to right the old_x% 
should be smaller than the new_x% and vice versa. This direction is 
multiplied by the step_size% so that we know the STEP variable for the 
FOR/NEXT loop. The function of the loop is to print the string twice, firstly in 
the background colour and secondly in the foreground one at a slightly 
different position. The delay can be varied as you require and when the loop 
ends the string is reprinted in exactly the right position (it might not be right at 
the end of the loop due to the step size). Finally the cursors are separated 
before execution passes back to the main program. 


Figure 5.19 

1865@@ DEF PROCmove_vertical 
(old_y4,new_yZ,x_pos24,string) 

1851@ LOCAL position~Z,step~,direction“Z, 
step _sizez,delayz 

18520 IF 7&2361=@ PRINT“Not graphic 
mode":ENDPROC 

18530 step _sizex=16 
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i8340 


15558 
183560 
1657@ 


18582 
18590 
18688 
18610 
18620 
18630 
13648 
18650 
1866@ 
18670 
18680 
1869@ 
18700 
18710 
18720 
18730 
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YDU 3 

direction/4=SGN inew_y4Z-old_y@) 

stepZ=directioné*step sizer 

FOR position“=old_y% 

TO new_y4-step% STEF stepz 
MOVE x_posZ,positioanZ% 
GCOL @,@ 

PRINT strings; 

MOVE x_posZ%,positionAtstepZ 
SCOL @,1 

PRINT string; 
delay“A=INKEY (3) 

NEXT position2z 

MOVE x_pos%,positionz 

GCOL 4,6 

PRINT strings; 

MOVE x_posZ,new_yA 

GCOL @,1 

FRINT strings; 

VDU 4 

ENDPROC 


The only difference between the last procedure and this one is in the 
parameters and their use. Here they need to be the start and stop values for 
the y co-ordinates and the x position. The procedure then follows in exactly 
the same manner as the one above. 

To test this module try the following program: 


Figure 5.20 


1@ MODE1 

20 VDU 19,0,4,0,0,0,@ 

28 messaget="Hello!!" 

40 REPEAT 

58 PROCmove_horizontal 
(64,1000 ,64,message?) 

60 VDU 19,1,RND(7) ,0,0,0,0 

78 PROCmove_vertical 
(64,1000, 1000 ,message) 

8G VDU 19,1,RND(7) ,0@,0,0,08 

99 PROCmove_horizontal 
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(1000 ,64, 1000 ,message?) 
119@ ¥DU 19,1,RND(7) ,0,0,0,@8 
118 PROCmove_vertical 

(1000 ,64,64,message#) 
1228 VDU 19,1,RND(7) ,@,8,8,0 
120 UNTIL FALSE 
14@ END 


After setting the mode and the background colour to blue the message is 
moved first from left to right, then bottom to top, right to left and then top to 
bottom. The VDU 19 lines change colour 1 so that a range of colours is 
displayed. If this random number is 4 the message disappears; you can’t see 
blue writing on a blue background! 

These routines are used in several of the programs that follow. There are 
suggestions about how to change them so that they will move just a single 
space or block. By experimenting with them you will learn how best to use 
them. You can’t damage anything, so have a go! 


Module 11 _ Picture drawing module 


PROCdraw_picture. Lines 18500 to 18630. 
PROCdgcol. Lines 18640 to 18680. 
PROCdplot. Lines 18690 to 18730. 
PROCdpoly. Lines 18740 to 18780. 
PROCdcircle. Lines 18790 to 18830. 
PROCdrectangle. Lines 18840 to 18880. 
PROCrectangle. Lines 18890 to 18950. 


This set of procedures comprise a system for drawing simple screen pictures 
from DATA statements instead of all those MOVEs, DRAWs, GCOLs and 
PLOTs that are usually needed. We cannot claim that using the system is 
simple but it does save memory and if you can use the various geometric 
shapes available to draw your picture then we would recommend it to you. 
There is a full example of its use in a later chapter. 


Figure 5.21 

18500 DEF PROCdraw_picture 

185106 REPEAT 

18526 READ value 

19530 IF value<@ OR value>ss 
THEN 18620 
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18540 ON value GOTO 18570,18580, 
18590, 18600,18616 

18550 next pict=FALSE 

18360 FPROCread name 

183576 PROCdgcol:GOTO 18620 

18586 FROCdplot:GOTO 18620 

18576 PROCdpoly:GOTO 18620 

18408 PROCdcircle:GOTO 18620 

184610 PROCdrectangle 

18620 UNTIL value<-—i 

18636 ENDPROC 


This is the master procedure which READs the first DATA item and then 
decides which procedure needs to be called next. The ON GOTO structure 
allows us to test the value just once rather than having to test for each possible 
value. The values are decoded as follows: 


Value Meaning Number 
of 
parameters 

1 Perform GCOL 2 

2 Perform PLOT 3 

3 Draw polygon 5 

4 Draw circle 4 

5 Draw rectangle _ 4 


Execution is then passed to the correct routine and the parameters required 
for this particular action are READ in these procedures. By using this method 
we can accommodate procedures with different numbers of parameters. If 
these values were READ in the main procedure there would be a great deal of 
padding of the DATA statements where only a few parameters are needed. 


Figure 5.22 


18640 DEF PROCdgcol 
18650 LOCAL type,number 
18660 READ type,number 
18670 GCOL type,number 
13680 ENDPROC 


18696 
18700 
18716 
18720 
18736 


18746 
18756 


18760 


18770 


18786 


18790 
18806 
18810 
18820 


18836 


18846 
18830 
18860 
18870 


18880 


18890 


18900 
18916 
18920 
186936 
18940 
18956 
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DEF PROCdplot 

LOCAL number ,x_pos,y_pos 
READ number ,x pos,y_pos 

FLOT number ,x pos,y_pos 

ENDPROC 


DEF PROCdpoly 

LOCAL sides,x_pos,y_pos, 
radius,fill 

READ sides,x pos,y_pos, 
radius,fill 

PROCpoly (sides,x_ pos,y_pos, 
radius,fill) 

ENDPROC 


DEF PROCdcircle 

LOCAL x_pos,y_pos,radius,fill 
READ x_pos,y_pos,radius,fill 
PROCpoly(15,x_pos,y_pos, 
radius,f111) 

ENDPROC 


DEF PROCdrectangle 

LOCAL low_x,low_y,high_x,high_y 
READ low_x,low_y,high_x,high_y 
PROCrectangle(low_x,low_y, 
high_x,high_y) 

ENDPROC 


DEF PROCrectangle(low_x,low_y, 
high_x,high_y? 

MOVE low_x,low_y 

DRAW high_x,low_y 

FLOT 85,high_x,high_y 

DRAW low_x ,high_y 

PLOT 85,low_x,low_y 

ENDPROC 


89 
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The operation of these procedures is fairly obvious as they follow the 
normal BBC BASIC pattern. Full details of the various statements that they 
replace are to be found in the user guides. If you wish to extend the range of 
drawing options by including a shape-filling routine, for example, it is quite 
easy to extend the first, master procedure to call another routine that you 
have written yourself. | 

To test this module you need a group of data statements to draw the 
picture. The program below uses just a few to draw a simple, hopefully 
recognizable, shape. You will also need to add the procedure PROCpoly that 
you typed in earlier, as this is required by the module. 


Figure 5.23 


14@ MODE 2 
PROCdraw_picture 


20 
38 


1000 
10108 
1626 
1030 
1640 
1@5@ 
1440 
1070 
1050 
1490 
1100 
1116 
1120 
1138 
1144 
115@ 
11640 
1170 
1180 


END 


REM Face Data. 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,90,5 
4,600,500,400,-1 
1,0,15 
4,400,600,100,-1 
4,800,600,100,-1 
1,0,2 
3,3,600,450,50,-1 
1,0,@8 

5, 350,250,850, 350 
1,8,7 ° 

5,500, 250,550,300 
5,600, 300,650,350 
1,0,4 
2,4,300, 600 
?,5,500,4600 
2,4,700,600 
245,700,600 

—2 
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This module might be used to give more interest to the title screens for your 
programs. In mode 2 you have the chance to produce really spectacular 
effects using all the colours; you might even be able to produce some 
animation by using PROCcolourchange too. 


Module 12 Sound routines 


FNvolume. Lines 19000 to 19080. 
PROCtune. Lines 19500 to 19600. 


It would be possible to write a book about the sound facilities of these 
machines. From the viewpoint of educational programming, however, we 
have provided just the two routines we think will prove most valuable. The 
first, whilst it can be used on the Electron to turn the sound off or on, works 
properly only on the BBC machine. It is used to give control of the volume to 
the user. The second routine needs to have a set of DATA statements to give 
it a tune to play, so we provide some test data in the section on testing. 


Figure 5.24 


19000 DEFFNvolume 

19416 LOCAL volumeZ 

19020 volumeZ%Z=-16 

190230 REPEAT 

19640 volumeA=volumeszt+i 

19030 SOUND1 ,volumeZ,101,20 
179060 IF volumes >@volumesz=—-1é6 
19076 UNTIL INKEY (100) =32 
1908Q0 =volume% 


This simple routine, which only works as described here on the BBC, 
allows you to decide how loud to have the volume set for later in the 
program. The routine comprises a REPEAT/UNTIL loop which cycles around 
until the space bar is pressed. During the cycling, a sound is generated at 
differing levels; all you have to do is press the space bar at the level of sound 
you find acceptable. There are no prompts in the function as we felt this 
would be best done in the main program. The function works by constantly 
incrementing the variable volume and therefore decreasing the sound level. 
When the space bar is pressed the variable is returned. This may then be used 
in any future SOUND statements. Line 19060 checks to see if the volume has 
been incremented beyond 0 and resets it to —16 to start at full volume again. 
The reason that this doesn’t work on the Electron is that the SOUND 
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statement can accept only two volume values, 0 and —15. Any other value is 
assumed to be —15 so the sound remains at a constant level. This means that 
whenever you press the space bar and there is a sound it will be set to full 
volume; the only alternative is off, i.e. pressing the bar during the silence. 


Figure 5.25 


19500 DEFPROCtune (lengthZ,tempo) 

193516 LOCAL pitch’, durationZ, volume 

19520 REPEAT 

195308 READ pitch’, durationz 

195408 IFpitch4=560 AND duration~=@ 
ENDPROC 

19350 volume4Z=15* (pitchZé< >@) 

19560 SOUND 1,volumeZ4,pitch’Z, 
duration“z*tempo 

19570 SOUND 1,0,0,1 

19580 lengthZ=lengthZ-1 

193598 UNTIL lengthz=@ 

19600 ENDFROC 


This routine as its name implies is a tune-playing procedure. The tune 
needs to be placed in DATA statements somewhere in the program and the 
DATA pointer must be set to point to it before calling the procedure. 
RESTORE is used to do this — full details are in the computer manuals. Each 
note to be played needs to be stored as two values. The first specifies the tone 
to be played (pitch%) and the second the duration of the tone (duration%). 
We suggest that you adopt the following convention for the duration, 
although you are free to devise your own method if you wish. 


Duration Note 

1 Semi-quaver 

2 Quaver 

4 Crochet 

8  Minim 

16 Semi-breve 

Dotted notes can be accommodated in between these values as required. 
This doesn’t mean that we can play the tune at only one speed; it can be 
varied enormously by the use of the second parameter that you supply to the 
procedure. This value (tempo) can be set to speed the tune up or slow it 
down and because it is a ‘real’ variable it can have a decimal value too. This 
makes it possible to fine-tune the speed until you are completely satisfied, and 
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saves a great deal of time when coding the tune. All the duration is used for is 
to set the ratio of the length of one note relative to the others. 

The values are READ from the DATA on line 19530. The next line checks 
for terminal values, pitch of 500 and duration 0, and ends the procedure if 
these values are found. This enables you to play to the end of the tune by 
putting some ridiculous value as the first parameter. This value (length%) is 
usually used to set the last note that you wish to play, which means that you 
can use the same DATA and tune several times during the program but to 
different effects by stopping in different places. If you require a rest in the 
middle of the piece to be played, you should use a pitch of 0. This is trapped 
on line 19550 where the volume is set by multiplying a logical value for the 
expression (pitch%<>0) by 15. The expression can be only either TRUE, if 
the pitch isn’t zero, or FALSE, if it is zero. We know that the machine gives 
TRUE the value —1’ and FALSE the value ‘0’. So if the pitch is zero we 
multiply 15 by O and the volume is set to O or silence. Otherwise the 15 is 
multiplied by —1 which gives a result of —15 or full volume. It is very simple to 
set the maximum volume to be played; you might have set this from 
FNvolume, by substituting your volume level for the 15 in line 19550. It 
would then read: 


19550 volume%=maxvol%*pitch%<>0) 


The sound itself is played on line 19560 and it is stopped by inserting a 
short rest on line 19570. If this is not done there is no obvious gap between 
notes of the same pitch, so no rhythm is heard. The length parameter is then 
decremented and the routine stops if this has reached zero. This is an 
example of a procedure with more than one exit as we described in the 
previous chapter. | 

In order to test this procedure we need some DATA lines too. In this test 
program there is a short tune to try. It is played several times at differing 
tempos and with different tune lengths. 


Figure 5.26 

i@ RESTORE 1000 

20 PROCtune (4,3) 

3@ A=INKEY (380) 

40 RESTORE 1000 

5@ PROCtune(12,1.5) 
40 A=INKEY (3a) 

7@ RESTORE 1000 

8@ PROCtune (500,2.5) 
9@ A=INKEY (30@) 

10@ RESTORE 1000 
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11M FROCtune(15,2.5) 
120 PROCtune (5@@, 2?) 
i3@ END 


940 REM Music Data- I am a Music Man 

140@ DATAI@1 ,4,137,2,137,2,137,2, 
137,2,137,6 

1014 DATAI37 ,2,137,2,137,2,141,2, 
137,2 

1020 DATA129,2,149,2,149,2,149,2, 
137,2,129,8 

14306 DATA1L4S ,2,149,2,149,2,137,2,129,8 

1040 DATA137 ,2,137,2,137,2,137,4,121,4 

1034 DATASO@ ,@ 


By adjusting the tempo parameters passed to the procedure you can 
fine-tune the speed to your liking; try this too. 

Use this routine whenever you want to play music. It is possible to use 
several different tunes by keeping the data separate and ending each set of 
lines with 500,0. Then you just RESTORE to the set of DATA that you want 
and call the procedure. What we tend to do is use just one tune but use it at a 
number of note lengths. 


That concludes the output modules. We hope you already want to try them 
in programs of your own. But before you do so, type in the modules from 
Chapter 6, as these will provide you with invaluable procedures to be used 
when you want the program user to tell the computer something. 
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Module 13. General-purpose input routine 


FNgpinput. Lines 20000 to 20180. 
FNeffect. Lines 20210 to 20300. 
FNrange. Lines 20330 to 20410. 
FN read_led. Lines 20440 to 20460. 
PROCwrite_led. Lines 20490 to 20520. 


Many times during a program we need to get some type of input from the 
user. In educational programs it is vital to ensure that the child cannot input 
anything which would cause the program to react in an unexpected way. In 
other words all input should be carefully validated before being accepted. The 
heart of this module is a very flexible data validation routine which can be set 
in different, ways depending upon the input required. It has the effect of 
placing on screen a line of full stops, one for each of the letters to be accepted. 
It is important to understand how this procedure works in detail so that you 
can use it properly and well. 


Figure 6.1 


2000@ DEF FNgpinput (lenZ,effect%,valid#) 
2601@ LOCAL delete#,returns,status/~Z, 
back space#,char#,first24,stringt 


95 


96 


280020 
20030 


20048 


20050 
28066 
24078 
200308 
260496 
20106 


26116 


24120 


20130 


26146 
261356 
2414@ 


201706 
24180 
24190 
20206 
20210 
20276 


26230 
20240 


209250 
20260 


20270 
20286 
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*FX15,1 


del etet=CHRS (1277) :return#s=CHRS (13) 


sback space$=CHR$ (8) s:strings="" 
PRINT STRINGS (lenZ,".")3 
STRINGS (lenZ ,back_space$) 5; 
status/A=FNread_ led 
REPEAT 
PROCwrite_led(48) 
char +=GET? 
IF char#=return? THEN 
IF chart=deletes AND 
LEN (string?) >@ THEN 
string#=LEFT?# (strings, 
LEN (string#)—1):PRINT 
back space#;"."sback_ space$s;: 
GOTO 26140 
IF INSTR (valid#,char?)=0 OR 
LEN(string?)=lenZ THEN 
VDU 7:GOTO 20166 
IF LEN(string#)=@ THEN 
firstZ=TRUE ELSE firstA=FALSE 
char $=FNef fect 
(chars, eftfect4,firstZ) 
PRINT chars; 
stringt=stringt+chars 
UNTIL chart=returns AND 
strings<>"" 
PROCwrite_led(statusZ) 
=string? 


20160 


DEF FNeffect (chars, effect“, first) 


ON effect% GOTO 20230, 26240, 
202566 , 20288 

=char? 

IF INSTR(CFNrange("a..z") ,char) 
THEN char #4=CHRS (ASC (char 4) -—32) 
=char + 

IF INSTR (FNrange ("A..Z") ,char#) 
THEN char #=CHR$ (ASC (char) +32) 
=chars 

IF INSTR(FNrange("“a..z") ,char?) 
AND first% THEN 
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char $=CHR$ (ASC (char $) —-32) 
20296 IF INSTR(FNrange("A..Z") ,char?) 
AND NOT first% THEN 
char #=CHR$# (ASC (char #) +32) 
20300 =chart 
206310 : 
20220 : 
29250 DEF FNrange (range?) 
26346 LOCAL first%, last%, strings, 
char% 
203356 firstZ=-ASC (LEFT (ranges,1)) 
20360 lastZ=ASC (RIGHTS (range#,1)) 
20370 string#="" 
20380 FOR char%=first% TO lastz 
20396 string?=string#+CHRs (char) 
20400 NEXT charZz 
204146 =stringt 
20420 =: 
20430 : 
24440 DEF FNread_ led 
26458 AZ=S&CAs XZ4=@: YZ=RFF 
20460 =((CUSR(&SFFF4) AND &FFFF) DIV &18@0) 
20470 : 
294808 : 
20490 DEF PROCwrite_led(status/) 
26306 AZ=SECA: X4Z=statuscé: YA=6 
203516 CALL &FFF4 
293520 ENDPROC 


The master function (FNgpinput) has three parameters. First len% specifies 
the maximum length of the string that may be input. There is no check on 
minimum length except that a null string (““) is not accepted (line 20160 
contains this check). The second parameter is effect% which is used to specify 
the style of string acceptable. There are four options available, as shown in 
this table: 
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Table 6.1 


Option Effect 

All characters accepted as typed. 

Characters typed are converted to upper case. 

Characters typed are all converted to lower case. 

The first character is converted to upper case, others to 
lower case. 


Bm WN ee 


The final parameter, valid$, is used to specify all the characters acceptable 
to the current input. All other characters are ‘trapped’ as they are pressed and 
a bleep is output as a warning. It is simplicity itself to ensure that only valid 
key-presses are accepted. In the case of normal alphabetic characters, valid$ 
must always contain the lower case characters as the function sets the 
keyboard to lower case input only on line 20070. If you place only capital 
letters in the valid$ then none of these letters can be accepted, unless the user 
keeps his finger on the SHIFT key. This shouldn’t present any problems, 
though, because you can set effect% to do all the conversions you need. 

Line 20020 is used to make sure that any inadvertent key-presses are 
cleared from the buffer and only key-presses after the prompt are accepted. 
The next line is vital to the function as using these variables allows us to clear 
unwanted key-presses both from the string being input and from the screen. 
There are several variables to be set: delete$ is the character that the DELETE 
key places in the buffer; return$ is set to 13, the value of the RETURN key; 
back_space$ is used when wiping unwanted characters from the screen — it 
moves the cursor back one position. Finally, the output string (string$) is set to 
a null value, i.e. to have nothing in it at all. Line 20040 prints out the correct 
number of full stops, in the last TAB position, and then moves the cursor back 
to the beginning, presuming you have the cursor visible! 

So that we can reset the leds, on the left of the keyboard, to the same state 
that they were in when we entered this function, there is a function to read 
their status. This can be used with the ‘write_led’ procedure to set the leds 
and, of course, the associated keyboard input to any setting that we need. 
Then we enter the main function loop on line 20060. In this loop the 
keyboard is set to lower case, just in case someone has tried to set it back to 
capitals, and the next key pressed is read by the GET$ statement. Then the 
testing begins. We are checking for certain key-presses or conditions; these 
can be best summarized in a table. 
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Table 6.2 
Check for Action taken by function 
RETURN Jumps to end of loop. If the input string contains 
no characters, the loop is re-entered. Lines 
20090 and 20160. 
DELETE If this key is pressed and there are already some 


characters in the string, the last one input is 
removed and the full stop reprinted in the correct 
location. Line 20100. 


Invalid character Bell sounds (VDU 7) and the input is ignored. 
Line 20110. 


Too many characters Action taken as described above. RETURN must 
end the input. Line 20110. 


First character Set a flag which is used by FNeffect to convert 


this character to upper case if required. Line 
20120. 


Valid key-presses are taken to be those that get through all the tests above 
unscathed! The character is sent as a parameter to FNeffect, where the 
required conversion takes place, and then the converted character is printed 
on screen. It is then added to the string which will be returned at the end of 
the execution of the function, line 20180. Before the string is returned, the 
leds are reset to the same state as when we entered the function by line 
20170. 

The parameters for FNeffect are: firstly, the character to be checked 
(char$); secondly, the effect desired (effect%); and finally, the flag to indicate 
whether this is the first character of the string (first%). The meanings of the 
effect numbers are shown in table 6.1 above. The ON GOTO is used to save 
having mntiple tests and it passes execution to the correct piece code for the 
option’ required. Option 1 allows input as typed so returns the character 
completely unchanged. Option 2 changes all lower case letters to upper case 
by adding a value of 32 to the code. Number 3 is not really needed, for, as we 
explained earlier, the only type of alphabetic input allowed is lower case; the 
reason that we have included the code is so that you can use it in your own 
programs if you don’t want to use this module in its present form. Option 4 is 
used when proper nouns are to be input. What is needed here is for the first 
letter to become upper case whilst the rest remain in lower case. By testing the 
flag first% this action is taken or the character is returned without change. All 
the options finish with the new character being returned to the main function; 
.e. there are a large number of possible exits to this function. 

The single parameter passed to FNrange is a string containing only the 
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upper and lower limits of the characters allowable. The purpose of the 
function is to make a string of all the acceptable characters, bounded by the 
two passed as the parameter, and return this to the main function. You may 
ask, ‘Why go to all this trouble?’ The answer lies in the perversity of men and 
machines. If you don’t use a function such as this, there is a greater likelihood 
that you will miss out a letter of the alphabet or one of your chosen keys. You 
could use a range checking routine in a very similar way but some of the 
niceties would be missing. If you need to set up a string variable with just the 
alphabetic characters included it can be done very simply using the statement 
‘alpha$ = FNrange(‘‘A..Z”) + FNrange(“a..z”)’. Incidentally the full stops 
don’t actually do anything; they are used to separate for better readability. 

The procedure works by finding the ASCII value of the first character in the 
range$ and the value of the last character also. Then it makes up a string 
containing all the characters whose ASCII value lies between the values set. 
This is done within a FOR/NEXT loop with the upper and lower values as the 
initial and final values. 

The final two routines are the ones mentioned earlier dealing with the state 
of the keyboard input and the associated leds. As mentioned in Appendix 3, 
these routines will not work on those machines with the issue 0.1 operating 
system. They simply set up the variables required for the call to the operating 
system routine OSBYTE. This is the routine used by the more familiar *FX 
calls, but you cannot read values using *FX so we have to read the original 
state by using this method. A full explanation of this type of call can be found 
in the user manuals. . 

This routine works in exactly the same manner independent of mode and 
location on-screen. The following short program demonstrates all the effects 
and routines. 


Figure 6.2 

1@ MODES 

206 VDUI9,0,4,40,0,@ 

34 FOR effect=1 TO 4 

40 PRINT"Type a word now "; 

27 wor d?=FNgpinput (10,effect, 
FNrange ("A..Z")+FNrange("a..z")) 

6 PRINT 

7@ PRINT“Effect = "seffect 

80 FRINT "Word = “sword? 

78 PRINT 

100 NEXT effect 

110 PRINT"Now try a number "s; 


Input and Other Programming Modules 101 


120 number #=FNgpinput (16,1, 
FNrange("@..9")) 

120 PRINT 

140 FRINT"That was the number "; 
number + 

150 PRINT"But remember that this is 
held as a" 


17@ END 


This program simply loops around using different effects before giving you 
the chance to try the numbers. Don’t forget to try pressing some unacceptable 
keys too. In order to prove that option 1 works, type a few letters with your 
finger on the SHIFT key. 

We would use this type of routine on every occasion when an input is 
requested from a user. It can be used to input numbers, by converting the 
string returned into a numeric variable by using the VAL function; e.g. 
number% = VAL(number$). The whole module is, we admit, a little lengthy 
as it stands, so you might want to use more restricted versions in your ' 
programs, which is why we have gone to such lengths in this documentation. 
If you consider the functions that you need in a particular program and then 
‘tailor’ this module to suit, you will be saving a great deal of redundant code. 
You will find a number of these ‘cut-down’ procedures in the programs 
printed in later chapters. FNrange can be useful in any program, with or 
without the other routines, where you need to build a string from one 
character to another, and it is used in the ‘Save man’ game in this way. 


Module 14 Numerical input routine 


FNnumeric. Lines 21000 to 21210. 
PROCdelete. Lines 21230 to 21270. 
PROCadd_char. Lines 21290 to 21320. 


Although, as we explained above, FNgpinput can be used for numeric input, 
there are cases where it would be quite difficult to validate such input. An 
example of this might be where you needed a number with a set maximum 
number of decimal places. FNgpinput couldn’t prevent two decimal points 
being input or a plus or minus sign in positions that make numeric nonsense. 
With this type of restriction in mind we developed this module of routines. 
They allow you to specify the maximum length of the number as well as the 
number of decimal places to be allowed, if any. The only numerical input that 
it cannot cope with is exponential format, but this is by design not omission. 
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Figure 6.3 


21000 
21010 


21020 
21036 


~1040 
21050 
21060 
21070 
21080 
21090 
~1160 
21110 
21128 


21130 
21146 


2£115@ 


21160 


21170 


21180 


21190 
21200 


21210 
21226 
21230 
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DEFFNnumeric (len%,dplacesZ) 
LOCAL numerics,plusminus#, 
dpoint?,number#? ,delete#,returnt? 
#FX1iS,1 
plusminus#="+—-"sdpoint#s="._"s 
del ete#=CHRS (127) 
returnS=CHR$ (13) sbackspaces= 
CHR (8) number $="":chars="" 
numer ic#="@0123456789" 
used dp“A=FALSE: decimal Z=TRUE 
IF dplaces“4=0 THEN decimal %= 
FALSE:used dp%=TRUE 
PRINTSTRINGS (lenZ," ="); 
STRINGS (lend ,backspace$) 5 
REPEAT 
#FX2O2 , 32 
charts=GETS#:1F chart=return? 
THEN 21200 
IF char#=delete# AND 
LEN (number?) >@ THEN PROCdelete: 
GOTO21 200 ; 
IF LENinumber#)=lenZ% THEN 21190 
IF INSTR (plusminus?,char?) AND 
LEN (number #)=@ THEN 
PROCadd char:GOTO 21200 
IF chart#=dpoints AND NOT 
used dp% THEN used _dp%=TRUE: 
FROCadd_char :GO0T021200 
num_dplaces/A=LEN (number) 
—-INSTR (number #,dpoint#?) 
IF decimalA AND num_dplaces~z 
=dplaces% AND used _dp% THEN 
GOTO 21196 
IF INSTR (numerics,char?) THEN 
PROCadd_ char : GOTO21200 
VDU?7 
UNTILchar#=return? AND 
number $< >"" 
=VAL (number +) 


DEFPROCdelete 
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21240 IF RIGHTS (number#,1)=dpoint% THEN 
used dp“Z=FALSE 

212546 number $=LEF TS (numbers, 
LEN (number?) -1) 

21260 PRINTBbackspacet;" "sbackspace#; 

21276 ENDPROC 

21288 : 

21290 DEFPROCadd_ char 

£13080 number #=number #+char$ 

21310 PRINT char$; 

21326 ENDPROC 


There are great similarities between this function and the one detailed above, 
so some of this explanation will simply refer back to that module. 

The parameters passed to the function are all used to specify the type of 
input allowed. The first is the number of characters allowable (len%), whilst 
the second is used to set the maximum number of decimal places (dplaces%). 
This function doesn’t force a particular number of decimal places to be input 
but can be set to allow a certain number. After defining the local variables, we 
again use *FX15,1 to flush the buffer and set up the variables we require 
later. These are the same as before with a couple of additions. The variables 
numeric$, plusminus$ and dpoint$ take the place of the parameter valid$ 
because here we don’t need to give the user any options about the characters 
allowable. As numbers can be both positive and negative the two associated 
signs need to be accepted by the function but only in the initial position. 

The use of the decimal point is equally straightforward. On line 21060 the 
two flags to be used later are set to their initial values. If the number of 
decimal places set by the parameter is zero then we are requiring an integer, 
so there is a test for this and the flag (decimal%) is set to FALSE on line 
21070. On the same line another flag is set (used_dp%) to show that the 
input of a decimal point is not allowed. The next line, 21080, prints out an 
underline character for every character of the required length and the cursor 
is moved.to the beginning of this line. The main loop of the function follows, 
starting this time with a *FX call to set the keyboard mode and the associated 
leds. This is the exact equivalent of the PROCwrite_led in the module above, 
and is included here because we haven’t gone to the extent of storing the old 
value, so that we can reset the mode later. If you need to have that facility, 
using the two routines from the previous module will make it possible. The 
next character in the input buffer is then read by the GET$ and tested. The 
tests are similar to those in the last module so we have used a similar table to 
explain them. 
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Table 6.3 
Check for Action taken by function 
RETURN Jumps to end of loop. If the input string contains no 
characters, the loop is re-entered. Lines 21110 and 
21200. ; 
DELETE If this key is pressed and there are already some 


characters in the string, the last one input is removed 
and the underline reprinted in the correct location. 
The removal of the character is more complex here 
due to the meaning of characters, other than numbers, 
so control is passed to a procedure PROCdelete which 
is explained below. Line 21120. 


Too many Bell sounds and the input is ignored. RETURN must 


characters end the input. Line 21130. 

Plus or Check to see if these are in the first position. If so 

minus sign accept them; if not sound bell and ignore input. Line 
21140. 


Decimal point If not already used, flag (used_dp%) is set and the 
character added. Otherwise bell sounds and input is 
ignored. Line 21150. 


Too many The number of decimal places is found on line 21160. 
decimal places _If there have already been enough characters after the 
point, bell sounds and input is ignored. Line 21170. 


Numbers Numbers are accepted. All other characters are 
ignored with the ever-present bell sound as a warning. 
Line 21180. 


In this function it is the invalid characters that survive the tests due to the 
use of the PROCadd_char. This saves a great deal of extra code, hence its use 
as an external procedure. Line 21190 is the bell sound used in so many of the 
cases and the next line is the end of the loop. If there is a valid string and the 
last key-press was RETURN, the loop ends. To tur the string into a numeric 
value we use the VAL function, line 21210. It is this value that is returned by 
the function, not the string that we used as a temporary store. 

PROCdelete is needed to cope with all the flags that are needed in this 
function. It would be simple enough to delete the last character input but if 
this is a decimal point then we would have problems later as the flag would 
say that it had been used already. Line 21240 checks to see if this is the case 
and resets the flag. Line 21250 removes the unwanted character, using 
LEFT$ to chop it off. The final requirement is to wipe it from the screen, 
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hence line 21260. The final procedure, PROCadd_char, does as its name 
suggests and adds the last character to the string. 

Testing this procedure is relatively simple compared with the last one. 
There are only three real tests to be done: a test for length, a test for a set 
number of decimal places, and a test using negative numbers. The following 
program prompts you to try all these tests. 


Figure 6.4 


14@ MODES 
20 VDU 19,0,4,0,0,@ 
24 PRINT"Try a three figure number "; 
40 number 4Z=FNnumeric (3,0) 
24 PRINT 
6@ PRINT"That became "snumber% 
7@ PRINT 
BO PRINT"Try a five figure number 
{ with decimal" 
94 PRINT"places if you want) "3; 
146 number=FNnumeric (5,2) 
11@ PRINT 
120 PRINT"That became ";number 
120 PRINT - | 
1406 PRINT"Try a negative number now "; 
1350 number 4=FNnumeric (7 ,@) 
168 PRINT 
174 PRINT"That became “snumberZ 
186 END 


Run this program a few times, pressing both valid and invalid keys at different 
times. Don’t forget to try the DELETE key; we don’t want to waste all. that 
work! —~ | 

Not too many unusual uses for this one. You could try getting your friends 
to type in their cash card numbers, though! 


Module 15 Yes and no imput 


FNyn. Lines 22000 to 22040. 


Quite a simple procedure, this. Its purpose is to give a TRUE or FALSE result 
to a question requiring a yes/no answer. If you touch the “Y’ key the result is 
TRUE; if you touch the ‘N’ key then FALSE is returned. 
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Figure 6.5 

22000 DEF FNyn 

22010 LOCAL ansZ 

220270 REPEAT ansZ = GET AND 223 

22830 UNTIL ans% = 89 OR ansi = 78 
2-040 IF ansZ% = 89 = TRUE ELSE = FALSE 


This is not the easiest routine to understand but it includes only one test, 
unlike others that you may have seen before. The REPEAT/UNTIL ensures 
that only the two keys ‘Y’ and ‘N’ cause a result and the ‘AND 223’, line 
22020, has the effect of changing the input to upper case from lower case. 
This means that setting the keyboard status to upper is unnecessary. It also 
prevents us having to check for both upper and lower case input. Line 22030 
will branch out of the loop only if the key pressed was ‘Y’, value 89, or ‘N’, 
value 78. The final line returns the value TRUE for “Y’, or FALSE for ‘N’. 

The use of the logical variables TRUE and FALSE means that we can test 
for the answer using the following type of construction: 


100 IF FNyn THEN PROCrun_game ELSE END 


This type of line might be used at the end of a game to see if another go is 
required. If “Y’ is pressed then execution is passed to PROCrun_game, if ‘N’ 
then the END is processed. There is no need to use the following 
construction: 


100 IF FNyn=TRUE. .. 


This is because we used logical variables and operators and it means that the 
two constructions are functionally identical. 

Testing this function is simplicity itself. All you need to do is type the 
following line as a command (i.e. straight from the keyboard): 


PRINT FNyn 


You should get a result of 0 if you pressed the ‘N’ key or —1 if you pressed the 
“‘Y’ key. Any other key-press should be ignored. 

The uses of this function are obvious. Ask a yes/no type question and it can 
find the answer. Notice, though, firstly there is no flushing of the keyboard 
buffer before we take the input. This means that there could be a ‘Y’ or ‘N’ 
already there although this is unlikely. If you want to flush the buffer, insert 
this line: 


22015 *FX 15,1 


Secondly, there is no reason why you cannot use the general-purpose input 
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module to do the same job. It is certainly capable of this type of input; use a 
valid$§ = “YNyn”. You would then have to devise your own tests to check 
string$ for which answer was given and you must press RETURN after the 
answer. For these reasons we suggest the use of this module instead. 


Module 16 String handling 
FNread__string. Lines 23000 to 23070. 


When you are using characters, which might be multicoloured and user 
defined, in moving graphical type programs it saves a great deal of memory to 
set up string variables to hold all the commands required. Due to BBC 
BASIC’s ‘“VDU’ command all the colour-changing information can be turned 
into numbers and built up into strings which can then be printed on the screen 
very simply. The lines to build up such strings can themselves use quite an 
amount of memory, so using a function like this can be vital. 


Figure 6.6 

22400 DEFFNread_ string (len?) 
23010 LOCALcounter%Z,chr2Z,strings 
200270 stringt="" 

22528030 FORcounter%=1TOlen%s 

25840 READchr Z n 
23050 $stringt=string?+CHR$ (chr) 
23060 NEXT 

22670 =strings 


The function itself is easy enough to explain. It simply takes the length 
parameter (len%) and READs that number of character codes, using a 
FOR/NEXT loop, out of a DATA statement. These codes are then converted 
into the characters, using CHR$, and added on to the end of the string to be 
returned. The use of the function is not so readily apparent, however. 

Let’s take a simple example to start with. Suppose we wanted to have a 
string called ‘alpha$’ which placed the letter ‘A’ on the screen and the letter 
‘B’ undemeath it. Whilst there are other ways to do this, we will use this 
module by firstly working out what is required. We need to move the cursor 
to the correct position and then print the ‘A’. Then, rather than doing another 
PRINT TAB, we can move the cursor down one line and back one space and 
print the ‘B’ under the ‘A’. There are ASCII codes which will do this for us — 
see section 34 of the BBC user quide (pp. 377, 389) or Appendix A of the 
Electron user guide (pp. 265, 268) for full details. These codes are mostly 
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used in VDU commands but any number that can be used in such a 
command can also be used in a string with the CHR$ function. So the code 
for cursor down a line is 10 and back a space is 8; a string to do our example 
might read: 


alpha$=“‘A”+CHR$(10)+CHR$(8)+“B” 


This works well but is cumbersome and it would be better if we could just use 
a few numbers instead. That is what this module allows. The DATA in this 
case would be just ‘65,10,8,66’, ‘65’ and ‘66’ being the ASCII codes for ‘A’ 
and ‘B’ respectively. This then provides us with short test program: 


Figure 6.7 

1@ MODE 6 

20 alphat=FNread_ string (4) 
~@ PRINT TAR(10,5) 3; alphas 
46 PRINT TAB(C15,10)3 alphas 
23@ END 

608 DATA6S,10,8,664 


That is only a simple example and by looking carefully through the user 
quide pages mentioned you will see that these codes can be used for all kinds 
of action. The main ones that we use — see “Answer invaders’ in Chapter 8 for 
example — are the colour-changing codes, 17 and 18, and the cursor control 
codes, 8 to 11. To demonstrate the use of such codes try the following 
example to test your module. 


Figure 6.8 


1@ MODE2 

£0 messaget=FNread string (41) 
2@ FORcounter=0@TO1G0 

4B PRINTTABCRND (18) ,RND(25))5 


message+ 
2 NEXTcounter 
66 REPEAT 


78 VDUI9,RND(S) ,RND(15) ,0,0,0 
8@ UNTILFALSE 

90 END 

1@0 DATA17,1,72,32,84,18,8,8,8 
110 DATAI7,2,1@1,32,104,10,8,8,8 
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120 DATAI7,2,108,32,101,18,8,8,8 
130 DATAI7,4,108,32,114,10,9,8,8 
140 DATAI7,5,111,32,1@1 


This test program will display a message vertically on the screen in five 
colours by using the single command PRINT message$. All the colour 
information is held in the string itself! The program prints the message ten 
times before entering an unending REPEAT/UNTIL loop (you must press 
ESCAPE to end it) which just changes the colours on the screen. By trying 
this technique with simple messages you will be able to employ it for 
user-defined graphic shapes in your own programs. This is explained further 
in the documentation for ‘Answer invaders’. 

Potential uses of this module are unlimited, or limited only by your 
imagination. After you understand its workings thoroughly all types of uses 
start to suggest themselves, especially in moving graphical games where 
multicoloured characters become possible and simple to use. A final test 
program will demonstrate this. 


Figure 6.9 


14 MODE? 

24 VDUS 

a4 PROCchars 

40 hen#t=FNread_string (5@) 

24 wipet=FNread string(7) 

60 FORcounter =1@@0TO@STEP—32 

70 MOVEcounter , 400 

3a FRINThHens 

70 A=GET 
140 MOVEcounter , 600 

114 PRINTwipet 

120 NEXTcounter 

130 END 

1480 DEFPROCchars 

150 VDU2S,227 ,62,63,95,95,120,112,8,08 
160 VDU2S , 228 ,6,0,0,0,192, 224,224,248 
170 VDU2Z3,229,184,112,2486,224,0,0,0,0 
186 VDU2Z3 ,230,0,0,0,0,0,32,32,32 

196 VDU2S, 231 ,64,64,0,0,0,0,224,161 
260 VDU2S ,232,48,56,12,24,48,24,12,4 
214 VDU2S,233,0,0,0,0,176,152,1356,220 
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220 VDLI23,234,8,0,0,8,0,8,0,2 

230 VDU2S,235,1,0,32,352,0,0,8,0 

240 VDU23,236,12,279,489,24,12,24,48,32 

250 VDU25,227,64,128,0,0,0,0,0,0 

260 VDU23 , 238, 255,255,255, 255,255, 255,255,255 

27@ ENDPROC 

280 DATA 18,0,3,226,8,18,0,1,230,8, 
18,0,0,234,18,0,3,2278,98,18, 
18,0,35,229,8,18,0,1,233,98, 
18,0,0,237,8,8,18,0,3,227,8, 
18,0,1,251,8,18,0,0,235 

298 DATA238, 2239, 10,8,9,238,238 


This shows how one multicoloured character can be defined as a string and 
then printed anywhere on the graphics screen. If we were to define a new set 
of characters with the hen standing, then we would have a hen that could be 
animated. You can see from the listing that there are a large number of 
character definitions involved in this type of programming. Although the 
amount of detailed work in the definition of the characters is sizeable, once 
this has been done, using this type of animation is very simple. 


Module 17 Sorts 


PROCselection_sort. Lines 30000 to 30110. 
PROCbubbie_sort. Lines 30130 to 30230. 
PROCripple_sort. Lines 30260 to 30380. 
PROCswop. Lines 30410 to 30460. 


You might assume that the sarting of lists and numbers was not likely to be 
needed in educational programming, but this would be a false assumption. 
There is a program that we use with remedial children who have a poor 
short-term memory span which involves remembering which houses have a 
letter to be delivered today. They remember the list and type it in, in any 
order; but so that the letters can be delivered they must be sorted into order, 
and a ‘sort routine’ is vital to such a program. There is a program in Chapter 8 
which uses one of these procedures to sort the letters of a word into 
alphabetical order ready for the game. So don’t dismiss this module as boring 
and useless. We think you may be surprised by the number of uses you will 
find for it. 

Because there are a large number of different sorting algorithms we have 
included three procedures all of which work in slightly different ways. There is 
no need to understand the logic of the sorts to be able to use them, but for 
those who like a challenge they are fully documented. The problem is often 
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which sort to use in a particular application. As there are a vast number of 
routines, and even of books which try to answer just that question, we will 
offer no advice except to suggest that you use the one you understand best! 

Unlike the other modules in this chapter there is no demonstration program 
here. This is because there is a full test in the program ‘Sort Demonstration’ in 
Chapter 8. 


Figure 6.10 


360600 DEF PROCselection_sort 
50610 LOCAL not_sorted, 
biggest_so_far,item 
546270 not_sorted=bottom_of list 
38038 REPEAT 
30040 biggest so far=top_of list 
35800350 FOR item=top_of_list TO 
not sorted 
34060 IF datatitem) > 
data(bigqgest_so far) THEN 
biggest so far=item 
38078 NEXT item 
50088 IF biqggest_so_far< >not_sorted 
AND data(biggest_so far)<>° 
data(not_sorted) THEN 
PROCswop (biggest_so_far, 
not_sorted) 
358670 not_sorted=not_sorted-1 
50100 UNTIL not_sorted=top_of_list 
524110 ENDPROC 
38120 : 
20120 DEF PROCbubble_ sort 
394146 LOCAL not_sorted,exchanged,item 
2015@ not_sorted=bottom_of_list 
3@16@ REPEAT 
20170 ex changed=FALSE 
320180 FOR item=top_of_list+t+i TO 
not sorted 
28196 IF datalitem)<datalitem-—1) 
THEN PROCswop (item,item-1) =: 
exchanged=TRUE 
202700 NEXT item 
28718 not sorted=not_sorted-1 


112 
3228 


3423508 
34240 
38258 
284268 
354270 
34280 
30296 
38308 
283160 
58328 
SO3.28 
34348 


3589358 
28568 


28376 


20380 
24290 
~8400 
324416 
38420 
34430 
30440 
34456 
304460 


The procedure which is central to all the sorts is PROCswop, despite its 
position at the end of the listing. The two parameters are the old and new 
positions of the item to be moved. This routine simply takes a number (or 
indeed a string if that is what is being sorted) from one position in the array 
and moves it to another position in the same array. We don’t want to lose 
what was already in that location, however, so we first save this into a 
temporary store; then it may be retrieved and put into the unused location 
later. That is all that these lines do and by reading them through it should be 
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UNTIL ¢ NOT exchanged ) OR 
not sorted=top_of_ list 
ENDPROC 


DEF PROCripple_ sort 
LOCAL exchanged,ripple_start,item 
ripple_start=top_of_ list 
REPEAT 
ripple start=ripple_start+l1 
ex changed=TRUE 
item=ripple_ start 
REPEAT 
IF datalitem)<datalitem—1) 
THEN PROCswop (item,item-—1) 
ELSE exchanged=FALSE 
item=item-—1 
UNTIL ( NOT exchanged ) OR 
item=top_of_list 
UNTIL ripple_start= 
bottom_of list 
ENDPROC 


DEF PROCswop (old,new) 
LOCAL temp 

temp=data (new) 

Gata (new) =data(lold) 
datalold)=temp 
ENDFROC 


clear and easy to see how it is achieved. 


All of the sort routines are written in such a way that there are a number of 


variables to be initialized in the main program. These are as follows: 
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1 The main array (string or numeric) should be DIMentioned and filled 
with the data to be sorted. | | 

2 The index number of the first item to be sorted should be assigned to 
the variable ‘top_of_list’. 

3 The index number of the last item to be sorted should be assigned to 
the variable ‘bottom_of_list’. 


This means that the procedures can be used to sort different arrays, by 
swopping the data into the sorting array before calling the procedure. This is 
made essential by BBC BASIC’s inability to pass the array name as a 
parameter to a procedure, a surprising yet not critical omission. It also allows 
us to sort only part of an array if we wish to do so; we have just to assign the 
start and finish points to the two variables mentioned above. 

Before going any further we need to decide upon the terms that we are 
going to use in the following discussion. It is very simple to confuse the two 
numbers involved in sorting procedures, i.e. the array index number and the 
array element value. If we imagine an array as a number of boxes one after 
another in a long line, they would all be numbered consecutively so that we 
know where the things we have put in the boxes are. This is the array index 
number. The fifth box along is number ‘5’, it is “box 5’ if we want to send 
someone to it. What box 5 contains could be anything, but suppose we are 
putting paper money in them, e.g. £1, £5 and £10 notes, each box then has a 
‘value’ as well as a number. Box 5 might contain a value of £10 and this we 
would refer to as the array element value. The array index,number 5 has an 
element value of £10; if you can keep the box number separate from the 
box’'s value, the following discussion will be easier to understand. 

The method used in a selection sort is to start at the top of a list looking for 
the largest value and when you have found it exchange it with whatever is in 
the bottom box. Then you know that the bottom value is in the correct place 
(it is the biggest value in the whole list), so you can ignore this in the future 
when finding the next biggest value to exchange into the next box up. Line 
30020 sets the ‘not_sorted’ pointer to the bottom index of the array to be 
sorted. This is the location into which we will put the biggest value that we find 
on this pass. The REPEAT/UNTIL loop is ended only when this pointer 
(not_sorted) is equal to the variable ‘top_of_list’, line 30100. We have to set 
the variable ‘biggest_so_far’ to the index of the first value that we are to use, 
which is what happens on line 30040. The FOR/NEXT loop which starts on 
line 30050 searches for the largest value left in the array and remembers 
where it is. Notice that it remembers only the index, not the value. This is 
achieved by line 30060 where the values are compared: if the ‘iter’ value is 
higher then ‘biggest_so_far’ is set to be ‘item’. When the loop terminates the 
element value of the index ‘biggest_so_far’ is the value that needs to be 
placed into the lowest location left. So we first check to see if the biggest is the 
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bottom location (biggest_so_far <> not sorted) and that the value of the 
biggest isn’t the same as the value of the lowest (data (biggest_so_far) <> 
data(not-sorted): If either of these were true, we would be making 
unnecessary exchanges; if they aren’t equal, the exchange is made, line 
30080. 

We next need to set the not_sorted pointer to one location higher in the list 
and start looking for the biggest value left. This proceeds UNTIL we have 
reached the top of the list. At this stage all the items are in numerical order, 
lowest first and largest last. | 

In a ‘bubble sort’ you are supposed to cause the smaller values to bubble to 
the top of the list. The logic of this is that you compare two values next to each 
other and if the one further down the list is lower than the one above it then 
the two are exchanged and so on. The effect of this is that at the end of one 
‘pass’, or run through, the item with the largest value will be at the bottom so 
we can ignore that location next time. This carries on until the pointer to the 
bottom is pointing at the top of the list or there have been no exchanges 
made, in which case they must all be in order anyway. 

The pointer (not_sorted) is initially set to be the bottom of the list to be 
sorted (bottom_of_list), line 30150. Then the loop starts to be finished only 
when the pointer is at the top, or there have been no exchanges made in that 
pass, lines 30160 and 30220. In order that we can know if any have been 
swopped we need to set a flag; this is done on line 30170, which is set to 
TRUE if there is an exchange, line 30190, to be checked at the end of the 
loop. The FOR/NEXT loop encloses the comparison routine and goes from 
the top of the list to the pointer, checking each value with the one above and 
exchanging if it has a value less than the one above, line 30190. Each pass 
ends on line 30200 and is followed by the pointer being moved one location 
higher, line 30210. The check to see if they are all in order yet (i.e. NOT 
exchanged) or we are at the top of the list occurs on line 30220. Then we 
have our finished list in the correct order just as before. 

In a ‘ripple sort’ we use the same basic comparison technique as we did in 
the bubble sort. We always compare one number with the one above. After 
an exchange is made instead of carrying on down the list we start comparing 
upwards to see if that value needs to move any higher up the list. The list is 
always in order above the pointer before we move it downwards. When the 
pointer is at the bottom of the list, all is in correct order and the routine may 
cease. 

As described above the pointer for the comparison is set to be the top of the 
list on line 30280. Then comes the outer of two nested REPEAT/UNTIL 
loops; here the pointer is moved down the list ready for the first comparison. 
So that we know when there has been no exchange we assume that there has 
been one, see line 30310, and set this flag to FALSE only if one doesn’t 
occur, line 30340, following the ELSE. We need to have a counter for the 
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inner of the two loops, so this is initialized on line 30320. This inner loop is 
where the comparisons are made and this code is identical to that in the 
bubble sort. If an exchange has been made then we go back through the 
already sorted list — notice that ‘item’ is decremented on line 30350 — and 
keep comparing until there is no further exchange or we are at the top again, 
line 30360. Then control is passed to the outer loop for the pointer to be 
moved down and another pass is made through the unsorted list. When the 
top pointer reaches the bottom of the list then they must all be sorted so the 
routine ends. 

To convert any of these procedures to sort a list of letters only involves 
changing the array name from ‘data’ to ‘data$’. The pointers need to be 
numbers in either case so these don’t change at all. 

As you can see, if you didn’t skip the last section, the type of technique 
used to sort a list can vary enormously. We hope that you can also see how 
capable humans are, when compared with even the best machine, in that we 
don’t have to think about how to perform such a simple act as sorting a list. 
There really is a great gulf to be bridged before any of these machines can be 
called intelligent. In order to make the workings of the sorts obvious we 
suggest that you type in the ‘Sort demonstration’ program in Chapter 8 and 
reread this explanation whilst watching that program. It shows all the locations 
and their contents and even how they move into and out of the temporary 
store. 


Module 18 Talking computer 
FNspeaker. Lines 31000 to 31030. 


For BBC users only, this routine will check to see if a machine is fitted with the 
Acorn speech synthesis upgrade. This can be important in a program where 
you intend to use speech because the machine will ‘hang up’ if you feed 
speech commands into the sound buffer and they cannot be processed 
because the speech chips aren’t present. Just as when you are using a printer, 
the routine will prevent this type of crash ever occurring. 


Figure 6.11 

51000 DEFFNspeaker 

3101@ LOCAL A%,X%,Y% 

518020 AXZ=235: X4=0: YAZ=0 

51030 =USR(&SFFF4) AND &FFOOOQ 
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There is an operating system, OSBYTE, call which tests the presence of the 
speech processor and this is used here to give a logical result. This means that 
the function will return a value of FALSE if there is no speech available or 
TRUE if there is. It is quite simple then to check this each time you intend to 
say a word. Such a test might look as follows: 


Figure 6.12 
150 IF FNspeaker then SOUND -1,465,8,9 


If the chips are fitted then the machine will say ‘A’ when this line is executed. 
Line 31020 sets up the variables for the call required (type 235) and the value 
returned is ‘masked’ out by the &FFOQ00 to give the TRUE or FALSE that we 
need. 

To test the function, type the following in command mode: 


PRINT FNspeaker 


If 1’ is printed then you can speak to your heart’s content. Otherwise it 
looks as if your machine is just as dumb as the rest of them! 

The application is quite obvious for this function but it might serve to 
demonstrate the use of certain OSBYTE calls in giving information that can 
be used by a programmer to modify the way that the program reacts as it runs 
on different machines. 


DEBUGGING AIDS 


The modules presented so far have all been to assist in the development of 
your own educational programs. The ones presented in this chapter are 
meant to help with all the programs that you either develop yourself, or type 
in from listings provided. You might even use them to help you type the 
listings given in this book. They don’t actually contribute anything to the 
program itself; their job is to help you to make the program error free and to 
simplify the programming task. 


Module 19_ ‘Error handling 


Error routine. Lines 32000 to 32130. 
PROCdebugkevys. Lines 32200 to 32320. 


When typing listings in from books or magazines, or when you are developing 
a program and testing it, you are bound to find errors of one kind or another. 
This module is meant to help identify those errors and make it simple to 
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correct or overcome them. The first routine, which cannot be called as a 
procedure but only by using a GOTO, tries to make the source of an error 
clear and calls the second routine to set up the function keys. Together they 
provide a development error-handling module which should speed up your 
programming enormously. 


Figure 6.13 

352000 REM ERROR 

32010 MODE6 

52026 VDU19,0,4;:0;@; 

32036 CLS 

32046 ONERROR OFF 

32050 *FX1i8 

52060 #K.@"LIST " 

22070 *K. IPROCdebugkeys: 
P.CHR#11;SPC4@0i°M 

32080 $&B146=STR# (ERL) 

3209@ REPORT 

32100 PRINT" at line "“;ERL 

22110 *#FX138,0,128 

52120 *FX138,0,129 

32134 END 


The first action taken here is to change to mode 6 and clear the screen to a 
blue background. Then we need to switch the error handling off, in case there 
is an error in this procedure which caused us to loop for ever. The *FX 18 call 
on line 32050 clears the soft (function) key definitions. This is*necessary 
because to list the line where the error occurs we need to know exactly to the 
byte what is in that area of memory. Line 32060 defines key 0 to contain the 
key word LIST followed by eight spaces. It is very important that the spaces 
are there and that this line is typed exactly as printed. This is because on line 
32080 we are going to ‘poke’ a number into the memory currently occupied 
by the spaces, so they need to be in exactly the right place. The next line 
defines key 1 to call the debugging key definitions when this routine is over. 
The PRINT statement (P.) is to wipe the call off the screen when we have 
made it. Line 32080 is the heart of the whole routine. It works by ‘poking’ the 
error line number, which is assigned by BBC BASIC to a pseudo-variable 
called ERL, into the function key definition buffer. We cannot use the number 
itself but can use the string of the number found by using STR$. We know 
that the word LIST is in key 0 and that there is space for even the largest line 
number allowed in BBC BASIC in the buffer due to the spaces. So by using 
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the ‘string indirection operator’ ($) we can make the key 0 definition list the 
line in which the error occurred. . 

It is also necessary to know what type of error it was and this is the function 
of lines 32090 and 32100. The following two lines both use *FX 138 to insert 
values into the keyboard buffer; this is simply a way of ‘fooling’ the machine 
into believing that a key has been pressed without actually pressing it! Line 
32110 is equivalent to pressing function key O and line 32120 function key 1. 
This means that when we end the routine, on line 32130, the line where 
BASIC believes the error to be will be listed and the function keys set ready 


for use in debugging. 

Figure 6.14 

32200 DEFPROCdebugkeys 

o22i@ *#K.@RUNIM 

32220 #K.1M0.6:ML.O@:ML.INIM 

se2250 #K.2M0.46:ML.07:MNL.iNIM 

o2e24Q #K. SMO.S:ML.INIM 

32250 *K.4P.CHR#113;CHRF11; 
"Frogram length = &"; 
~TOFP-FA. 3; SFCS@:M 

22268 #K.SDIM  i:P.CHR#11;CHR#11;5 
"Memory left after variables = 
&"s~H.-—_;SFCS@iM 

o22/8 #K.6L6.""9M 

32288 #k.7S5A. " 

32278 *#K. Oe. IM 

523600 #F.97AU. OM 

S2314@ #K.1i@0. 1M 

22528 ENDPROC 


This procedure sets up the function keys for use when debugging a 
program. The action of each key is described in the table below: 


Key number 


Ol & GW NO 


Action when pressed 


Program is RUN. 

Program is listed in MODE 6, paged mode on and with 
list option 0. 

As above but with list option 7. 

Program listed in MODE 3’s 80 column display. 

The length of the program is displayed. 

The amount of memory left, after the variables so far 
defined, is calculated and displayed. 
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6 The next program on the cassette is loaded. 

7 ‘SAVE “’ is printed ready for the program name. 
8 The cassette or disc is catalogued. 

AUTO line numbering is started (at line 10). 
BREAK OLD is performed to save the program. 


\O 


For BBC users we have used the minimum abbreviations for a number of the 
key words. This is because these words are stored as strings and if we used 
the whole word we might run out of memory. Electron users have the 
advantage here because they can use the single key-press system (CAPS 
LK,FUNC key plus a letter key) to save even more room. 

Most of these definitions work simply enough, so we have just explained 
the more interesting ones here. Line 32250 prints the program length; this is 
calculated by taking the value of TOP, i.e. the end of the BASIC program in 
memory, and subtracting PAGE, the start of the program. The result is 
displayed in hex just as it would be when loading the program. The rest of the 
line simply wipes the text used to do the calculation from the screen. 

Line 32260 uses a similar technique to calculate the memory left after the 
variables that have been defined by the program, up to the point where the 
error occurred, have been accounted for. The technique is to define a single 
element byte array using the variable names ‘_’ The underline character is 
one of the few non-alphabetic characters that can be used in variable names. 
As you are unlikely to include it in a program, we used it here, but it can be 
changed for any character you want. As this array was the last one defined it 
will be placed at the very top of memory; therefore if we find out where it is 
we know how much memory the program and variables have used. 
Unfortunately there are two sources of inaccuracy possible. The first is due to 
the error routine’s first command, which sets the machine into mode 6. We 
use HIMEM (H.), i.e. the bottom of screen memory, to find out how much 
space is left and this is reset when the mode is changed. We therefore suggest 
that when you know which mode you are going to use for your program, or 
the one requiring most memory if you are using more than one, you change 
line 32260 as shown in the table below. 


MODE(s) Line should read 


®, 1, 2 *#K.SDIM  £1:2:P.CHR#113;CHRS11; 
"Memory left after variables = 
&"s*&3000-—_3SPCSOiM 


td 


*#K.SDIM = 1:P.CHR#11;CHRF11; 
"Memory left after variables = 
&"s “240900—_;SPCS50iM 
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4, 35 *#KE.SDIM  1:2:FP.CHR#11;CHRF1135 
“Memory left after variables = 
&"s ~*5800-— ;:SPCSO:iM 


r=) *#E.SDIM  i:F.CHR#113sCHR#1i1; 
“Memory left after variables = 
&"5 ~&6000—-_5;SFPC50'M | 


By making these changes the major source of inaccuracy is avoided. 

The second source of inaccuracy is the space taken up by the single byte 
array itself, but as this is only four bytes it can be ignored. Anyone who is 
working to an accuracy of four bytes is in real and grave trouble! 

Line 32270 is fine for cassette users but should be changed by disc users as 
they must supply a program name. So they should alter this line to read as 
follows: 


32270 *K.6SA.” 


They will then need to type the last double quote, after they have specified 
the program name, and press RETURN too. 

Testing this module is very easy and can be great fun for here the game is 
to create a program with a number of errors so that the routine can be tested 
fully. The program below, which must be typed exactly as written, will give a 
number of interesting errors. Remember that as the line containing the error is 
printed at the top of the screen it is simple to copy and correct the line using 
the cursor keys. 


Figure 6.15 

=~ ON ERROR GOTO 32000 
146 FRIN "HELLO" 
20 PRINT “HELL 
3@ PRINT HELLO 
4@ READ HELLO 
50 RESTORE 5000 
60 ERROR 

7@ VALUE=0 
8@ end 
94 STOP 


The only line that doesn’t contain an error is line 90, so you should find 
plenty to do in correcting them. Line 70 is an interesting case of what can 
happen if you use upper case variable names. The variable starts with a 
BASIC reserved word (VAL), i.e. a BASIC command, and this is not allowed 
at the beginning of a variable name so a ‘Syntax Error’ is reported. By 
changing the variable to be lower case this problem is avoided. In case 
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anyone has difficulty in correcting these errors, a corrected version is shown 
below. 


Figure 6.16 

3 ON ERROR GOTO 32000 
14 PRINT "HELLO" 
26 PRINT “HELLO” 
of PRINT “HELLO” 
449 READ HELLO 
we RESTORE 1004 
74 value=6 

84 END 

74 STOP 
140 DATA 3 


Load this module into your computer before starting to type in a listing or 
develop your own programs. You will need to include a line equivalent to line 
5 above, so that the machine knows where to go in case of an error being 
found. This module cannot help to find minor programming ‘bugs’ as these 
might not lead to errors, but by pressing the ESCAPE key you can get the 
debugging keys set ready to find them yourself. Use a function keystrip to 
remind you of what each key does. The one on the back cover is ideal; you 
can cut this out or photocopy it if you prefer. 


Module 20 Program packing 


What we have so far failed to tell you is that there is a cost in developing 
programs in the manner that we have suggested. Using long variable names 
and inserting spaces between key words and variables costs valuable memory 
which in the Acorn machines is quite scarce as it is. What would be ideal is to 
be able to write a program in a way that is easy and simple to read and 
modify, yet still be able to use the high resolution modes and colours. If you 
take a great interest in products for the BBC machine you will have noticed 
ROM-based, packing programs being advertised. We use one a great deal but 
they are quite expensive. So we decided to write one ourselves in BASIC for 
you to use to reduce the size of your programs. 

You should always keep a normal and easy-to-read version of the program 
saved to tape or disc. This is due to the way that the packer works: it removes 
some spaces that you would normally have to type in from a keyboard. You 
cannot simply list and then copy a program line after it has been packed; it 
might not work if you do. The correct method is to go back and alter the 
original version and then repack it when you are certain that there are no 
more mistakes to be corrected. This is not a debugging tool as such, it is rather 
a programming aid to reduce the size of programs and allow you to use more 
memory than would otherwise be possible. 
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This program is, without doubt, in technical terms the most complex in the 
book. It requires not only an intimate knowledge of BASIC and its syntax but 
also a full understanding of the way that the Acorn microcomputers hold 
BASIC programs in memory. For this reason we will not be documenting this 
program in explanatory terms; it would probably take up half the book if we 
did. All we can provide is a full description of how and when to use the 
program, and this follows the listing itself. We would strongly advise against 
changing this program in any way, for unless you understand everything in 
full detail you are likely to have unpredictable results which might even cause 
you to corrupt the program. We also suggest that you read Appendix 3 again 
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before you type in the listing. 


Figure 6.17 


18 


178 


186 


MODE 6 

HIMEM=%43506 

FROCinitialise 

PROCset printer 

FROCLload program 
PROCcrunch_program 

PFROCpack program 
PROCsave_program 

END 

DEF FPROCinitialise 

DIM goto _tablez(3@), 
var_tablet(is@), 

crunch _tables(156) ,buffer 255 
quote=822 : hex=&26 : num_vars=6: 
goto=%8D : num_gqotos=0 : dim=%DE 
var_start="ABCDEFGHI JKELMNOPOR 
STUVWXYZ abcdefghi jklmnopqrstu 
VW yz" 
vart=var_start$+"@123456789" 3: 
hex $="@123456789ABCDEF " 

end of program=SFF =: return=8D : 
rem=3F4 =: star=ASC"*" =: on=SEE 


| data=%DC : then=%8C : else=&8B : 


colon=ASC ":" : def=&DD : 
spaces=FALSE 

space=32 : start_flag=TRUE : 
end of line=return =: if=E7 
flush=FALSE =: prog_start=HIMEM 
oscli=3FFF/7 =: os buffer=%A0G 


190 
200 


210 
228 
2—8 


240 
258 
260 


270 
2ae 
270 
300 


318 


328 


3S 

540 
iw‘) 
540 
3/70 
588 
390 


400 


41@. 


42°6 
436 


440 
436 
460 
47@ 
480 
490 
500 
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FOR loop=0@ TO 150 
var_table? (loop) =CHRS&FF = 
crunch_table# (1 cop) =CHRE&FF 
NEXT loop 

ENDPROC 

DEF FPROCload program 

INPUT “Type in filename of 

program — "filet 

$os_ buffer="LOAD "+files+" " 

+STRS™ (prog start) 

X4Z=os_buffer MOD &10@0 : 

Y2Z2=os_buffer DIV &100 

CALL oscli 

ENDPROC 

DEF PROCsave_ program 

INFUT “Type in packed program 

name — "filet 

tos buffer="SAVE "+files+" " 

+S TRS™ (prog_start)+" " 

+STRE™ (new _startt+2) 

X4Z=o0s_buffer MOD &%100 : 

YA4=os_buffer DIV %160 

CALL oscli 

ENDPROC 

DEF PROCcrunch_program 

VDU 26 : CLS | 

IF printer THEN VDU 2 ELSE VDU 3 

PRINT "Program — "3;files;° 

PRINT TAB(8)3;"Variable reference 

table."’ 

PRINT"Current Variable Name"; 

TAB (3@)3"New Name" 

PRINT 

VDU 28,0,24,39,6 

old_start=prog_start : 

old len=old_start73 

new start=prog_start 

Old_position=4 

REPEAT 
new position=4 
FOR loop=0 TO 2 

buffer ?loop=old_start?loop 
NEXT loop 


686 
596 
700 
710 
720 
7308 
740 
730 
740 
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PROCget_ next 
spaces=FALSE =: newline=FALSE : 
start flag=TRUE 
REPEAT 
PROCread spaces 
IF code=colon AND start_flag 
THEN PROCread_ colons 
IF code=dim THEN spaces=TRUE 
IF code=star AND start_flag 
THEN start_flag=FALSE =: 
PROCread to_end =: GOTO 6706 
IF code=rem OR code=return 
THEN newline=TRUE : GOTO 47@ 
IF code=data THEN 
PROCread to_end : newline=TRUE 
: GOTO 676 
IF code=quote THEN 
PROCread_ quote: GOTO 670 
IF code=hex THEN PROCread_hex 
: GOTO &7@ 
IF INSTR (var_start$, 
CHR? (code) )<>@ THEN 
PROCread_ variable : GOTO 67@ 
IF code=goto THEN PROCgoto : 
GOTO 467@ ; 
IF code=then OR code=else OR 
code=colon THEN start_flag 
=TRUE ELSE start_flag=FALSE 
PROCtransfer_ code 
PROCget_ next 
UNTIL newline OR old position 
>old_len 
new_lLlength=new_position 
FOR loop=0 TO new_length 
new start?loop=buftfer?7loop 
NEXT loop 
new_start?3=new_length 
new start=new_start+new_length 
PROCset pointers 
new start?@=return 
UNTIL old start?1=end_of_ program 


770 new_start?1=end_of_ program 
780 VDU 3 


790 
8H@ 
8108 
820 
830 
840 
850 
860 
876 
8380 
890 
700 
910 
92 
730 
740 
936 
966 
970 
9786 
9790 
1000 
101@ 
1026 


1030 


1046 
1@50 
1060 
1070 
1680 
1096 
1100 
1110 
1120 
1130 
1140 
1150 
11460 
11708 
1180 


119@ 
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ENDPROC 
DEF PROCread_ spaces 
IF spaces THEN ENDPROC 
REPEAT 
IF code=space THEN PROCget_next 
UNTIL code< >space 
ENDPROC 
DEF PROCread_to_end 
FOR loop=old position TO old_len 
PROCtransfer_code 
PROCget_next 
NEXT loop 
ENDPROC 
DEF FROCread quote 
REPEAT 
PROCtransfer_code 
PROCget_ next 
UNTIL code=quote 
PROCtransfer code 
PROCget_next 
ENDPROC 
DEF PROCread_hex 
REPEAT 
PROCtransfer_code 
PROCget_next 
UNTIL INSTR (hex ,CHR (code) )=@ 
ENDPROC 
DEF PROCread_ variable 
LOCAL string#,crunched$,char? 
PROCset variable 
PROCput_in_buffer 
ENDPROC 
DEF PROCset_ variable 
LOCAL loop,found 
string#=FNread_string 
found=FALSE 
loop=0 
REPEAT 
1 oop=looptil 
IF string#=var_tables(loop) 
THEN found=TRUE 
UNTIL found OR loop>num_vars 
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IF found THEN crunched?= 
crunch_table#(loop) : ENDPROC 
num_vars=num_varstl 
var_tables (num_vars)=strings 
crunched#=FNecrunch (num_vars) 


crunch_table% (num_vars) =crunched$ 


PRINT var_table?(num_vars) ; 

TAB (35) scrunch_table$(num_vars) 
ENDPROC . 

DEF PROCput_in_buffer 

LOCAL code 

FOR loop=1 TO LEN(crunched#) 


code=ASC (MIDS (crunched#,loop,1)) 


PROCtr ansfer_code 
NEXT loop 
ENDFROC 
DEF FNread_ string 
LOCAL string?,chart,loop 
string?="" 
char +=CHR$ (code) 
REPEAT 
strings=string#+chart 
PROCget_ next 
char $=CHRS (code) 
UNTIL INSTR (var?,char?) =0 
=string? 
DEF FNcrunch (loop) 
LOCAL crunched ,next,found,news 
cruncheds=LEF T# 
(var tablet (loop) ,1) 
IF NOT FNused (crunched) THEN 
=crunched? 
REPEAT 
next=ASC"a" 
REPEAT 
newt=cr unched#+CHR# (next) 
# ound=FNused (news) 
next=nextt+i 
UNTIL next >AsC 
found 
IF found THEN crunched#= 
crunched#+"a" 
UNTIL NOT found 


"z" OR NOT 


1378 
1586 
1n?e@ 
1600 
1618 
1620 


1636 
1648 
16256 
16608 
14678 
1468@ 
14696 
17046 
1716 
1720 
1736 
174 


1750 
1760 
1778 
178@ 
1790 
1800 
1816 
1820 
1838 


1848 
1838 
1860 
1876 
1880 
1890 
1900 


1910 
1920 
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=news 
DEF FNused (string?) 
LOCAL loop, found 


found=FALSE 

FOR loop=1 TO num_vars—i 
IF crunch_tabl e# (1 0o0p)=strings 
THEN found=TRUE 
NEXT | 

=found 

DEF FROCget next 


code=old start?Vold_ position 
Old position=old_ positiontl 
ENDFPROC 
DEF PROCtransfer code 
buffer ?new_position=code 
new position=new_positionti 
ENDPROC 
DEF FPROCgoto 
LOCAL code _ @%,code_1%4,code_ 224, 
Lline_num,loop,locationsz 
locationZz=old_ position 
FOR loop=i TO 4 
PROCtransfer_ code 
FROCget_ next 
NEXT loop 
code @%=old_start?iocationz 
code _1%4=old_ start? (locationszti) 
code 2%=oald_ start? (locationszt+2) 
line_num=(code_2% AND &3F)* 
&100+ (code _ 1% AND &3F) 
IF (code_@% AND 4)=@ THEN 
line_num=lLine_numt+k4006 
IF (code @% AND 16)=@ THEN 
line_num=line_numt+&40 
IF° (code_@% AND 32)=32 THEN 
line_num=l1ine_numt+&8@ 
IF FNused line(line_num) THEN 
ENDPROC 
num gotos=num_gotos+ti 
goto _ table (num_gotos)=line_num 
ENDFROC 
DEF PROCpack_program 
LOCAL vposZ%,prog_len,first 


128 
1938 
19408 


1930 
1960 
19708 
1986 
1990 
2006 
24108 
2020 
20308 
~H4@ 
2650 
2060 


20708 


2086 


2096 


2160 
21108 
2126 
2130 
2140 
2156 


2149 
217@ 
21804 
2190 
2200 
221@ 
2228 
2258 
2240 


2298 
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prog_len=ABS (new_start+ 
2-prog_ start) 
PRINT’ “Program length — "$s 
prog_len; 
vpos4A=VPO0S 
old _ start=prog_start 
new _start=prog_start 
Old _position=4 : new_position=4 
Old_len=old_start?3 
new_len=new_start?3 
FROCfirst_line 
FROCset pointers 
REPEAT 
new_len=old_ lentbuffer?3 
first=old_ start?74 
IF FNused line(line_num) THEN 
#lush=TRUE 
IF new_len>24@ THEN flush=TRUE 
IF first=def OR first=data OR 
first=star THEN flush=TRUE 
IF flush THEN PROCempty_buffer: 
FROCfirst line ELSE PROCadd_line 
PROCset pointers 
UNTIL old_start?1l=end_of_program 
PROCempty_buffer 
new start?@=return 
new _start?i=end_of program 
PRINT TAB(@,vposZ); 
"Program length — “sABS(new_startt 
2-prog_ start) 
ENDPROC 
DEF PROCread_ line 
LOCAL last 
last=-1 
PROCget_next 
IF code=end_of line THEN ENDPROC 
REPEAT 
REPEAT 
IF (code=colon) AND 
Clast=-1 OR last=colon) THEN 
PROCget next 
UNTIL NOT (¢code=colon) AND 
(last=-1 OR last=colon)) 
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IF code=end_ of line THEN 2320 
PROCtransfer_code 
IF code=data OR code=-if OR 
code=on THEN flush=TRUE 
IF code=star AND ( last=else 
OR last=then OR last=-1 ) THEN 
flush=TRUE 
last=code 
FROCget_ next 
UNTIL code=end_of_line 
ENDPROC 
DEF FNused_line(fline_num) 
LOCAL found,loop 
IF num_gotos=@ THEN =FALSE 
found=FALSE 
FOR loop=1 TO num_gotos 
IF goto _tableZ(loop)=line_num 
THEN found=TRUE 
NEXT loop 
=found 
DEF PROCempty_buffer 
LOCAL loop 
IF new_position=4 THEN 2500 
FOR loop=@ TO new_position 
new _start?loop=buftfer?loop 
NEXT loop 
new start=new_start+new_position 
new _start?@=-end_of line 
new _position=4 : flush=FALSE 
ENDPROC 
DEF PROCfirst_line 
LOCAL loop 
FOR lLoop=0 TQ 3 
buffer?loop=old_start?loop 
“NEXT loop 
new _position=4 
PROCread_line 
ENDPROC 
DEF PROCadd_ line 
IF old_len=4 THEN ENDPROC 
IF new_position< >4 THEN 
code=colon:PROCtransfer_code 
PROCread_line 
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130 


2649 
7650 
26460 
27678 
2680 
2698 
270@ 


2716 
2/26 
27358 
2746 
2730 
2766 
2/778 


2-780 
27970 


26800 LOCAL answers 

2810 REPEAT 

2820 CLS 

2830 PRINT TAB(13)5 "Program Packer." 

2848 PRINT TAB(@,2)3;"Do you wish to 
use a line printer 7 "3 

283356 printer=FNyn 

2666 printer _state=FNprinteron 

2376 IF printer_state=@ AND printer 
THEN PRINT TAB(@,4)3 "Please 
Switch on -the printer."; 
TAB(@,46) "Then press a key to 
continue. ": answer t=GET# 

2880 UNTIL printer_state OR 
(NOT printer > 

2890 CLS 

29706 ENDPROC 
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buf fer?7?3=new_position 
prog _len=prog_len-3 
FRINT TAB(C17,vpos%) sprog_len;”" 
ENDPROC 
DEF PROCread_colons 
REPEAT 
IF code=colon AND start_flag 
THEN PROCget_next 
UNTIL code< -colon 
ENDPROC 
DEF PROCset pointers 
old position=4 
Old _start=old_starttold_len 
old_len=oid_start7?3 
line_num=old_start?2+ 
old start?1#*#256 
ENDPROC 
DEF PROCset printer 


You also need to add on to this program the following two functions that you 
have already typed in. Follow the method detailed in Appendix 3 to add these 
to the program whilst it is still in memory. 


Input and Other Programming Modules 131 


Figure 6.18 
10406 DEF FNprinteron 
22406 DEF FNyn 


How to use the packer 
This program shortens BASIC programs in four distinct ways and aims to 
reduce them to the shortest possible size. This enables you to write programs 
using full variable names and spaces, to help readability, yet allows you to run 
them, once debugged, in the minimum amount of memory. 

The four methods used to reduce program size are: 


1 Removal of all unnecessary spaces. These may have been typed by 
the user to assist in readability or may have become unnecessary 
after ‘tokenization’. Because some of these spaces, those removed 
after tokenization, are essential when you type the program in at the 
keyboard, you must be very careful when making modifications 
using the cursor copying system. For this reason we suggest you 
always modify the original program and then repack it, thus 
preventing the possibility of such errors. 

2 Removal of all REMarks. As these are meant to help during 
development and often just take up memory space when left in 
finished versions, they can be removed with no ill effects to the 
program. . 

3 Shortening of variable names. The use of long variable names is 
essential to the type of programming that we recommend but they 
do use rather a lot of memory. This program will shorten all the 
variables used in a program to single- or two-letter length. To help 
you find your way around the program after packing, a conversion 
table is printed on screen and printer, if attached. 

4 Concatenation of program lines. It is much easier to debug and 
modify programs with single-statement lines. They do use memory, 
however, and valuable space can be created by using multi- 
statement lines. The program creates such lines and therefore saves 
the space by concatenating (joining) lines together to the maximum 
length allowed. 


Before you RUN this program, save a copy so that if anything goes wrong 
you haven't lost all your hard work. Then use the test program given below 
before you try to use it on anything important. The best way to check that it is 
working correctly is to compare the program that your version produces with 
the packed version printed below. If the lines are exactly the same, you 
should be all right, but this test program is not exhaustive and there may be 


132 Writing Educational Programs 


minor bugs still to be found. For this reason, after using the test program and 
its packed version as your first test, try to pack the packing program itself. Full 
details of how to do this are given after the short test program. 


Figure 6.19 Packer test program 
10 REM PACKER TEST 
27Q *FX 15 1 
2@ MODE 2 
4@ FOR counter = @ TO 100 
par Fa MOVE RND(10@00) ,RND (1000) 
40 DRAW RND (1000) ,RND (10@@0) 
78 GCOL @,RND(7) 
3@ NEXT counter 
90 FOR range = 1 TO 4 
100 ON range GOSUB 1000, 


2000 , 3000 , 4000 
110 NEXT range 
124 END 


120 *REM This line is left alone !!! 

1600 PRINT “One” 

1910 RETURN 

2400 PRINT "Two" 

2010 RETURN 

3000 PRINT "Three" 

32010 RETURN 

4000 PRINT "Four" 

4010 RETURN 


This should be changed by the packer into the following program. (Note that 
this listing is shown just as it would be on a mode 6 list with list option 0, and 
not like the other listings in the book. This is so that you can compare it with 
the listing you read on your screen. ) 


Figure 6.20 Packed version of the test 


20*FX151 

3@MODE2: FORc=@T01@@: MOVERND (1900) ,RND 
(19@@) : DRAWRND (19@@) ,RND (1@@@) : GCOL@,RND 
(7) :NEXTc: FORr=1T04: ON GOSUB1 800, 2000,30 
aa, 4000 
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LI@NEXTr:END 

12=Q0*#REM This line is left alone '!! 
1QOHOPRINT"One": RETURN 
POQSPRINT" Two":RETURN 
SHOGPRINT"’ Three": RETURN 
4QGGOPRINT"Four": RETURN 


There are a couple of things to take particular notice of. Firstly, line 130 has 
been preserved exactly as it was in the main program. This is because there 
was an ‘*’ at the beginning. This use of an asterisk to preserve a line can be 
most useful as mentioned later. Secondly, the ON GOTO lines have been 
fully preserved and all lines have the line numbering of the original program. 
This should ensure that the program will RUN exactly as before. 

Remember to RUN this packed program and make sure that it works 
exactly as it did before packing. The only change should be that it is shorter 
and will probably be faster; if you could measure micro-seconds you could 
check this! 

Now try to pack the packer itself. It is important to do this before using it on 
anything else. If you try to use the packer in its current form you can pack 
programs only up to five and a quarter kilobytes long. When it has been 
packed itself, it can be altered slightly and will then be able to pack programs 
up to eleven and a half kilobytes long, a vast improvement. The alteration 
needed after packing is to change the value of HIMEM to a lower figure. This 
value is used to prevent the packer’s variable space overwriting the program 
being packed. If there is not enough variable space, a ‘No room’ error will 
occur and this will simply stop the program. So if HIMEM is set too low the 
program can never work; conversely if it is set too high the packer can pack 
only small programs, which would be a waste. With HIMEM set at &4500, as 
it is in the program as listed, it is capable of packing itself — but once it is 
packed it will need less room and so HIMEM can be reset. So that this is 
possible you need to follow these instructions as carefully as possible. 


1 Save the packer as it is listed, at least once. 

2 Use it on the test program and compare the results to the program 
printed above. If it is the same, save the packer again, at least once. 

3 Re-load the packer into memory and change line 20 to read: 


- 20 *HIMEM=&3300 


Save this version as ‘PACKER2’ and if you are using cassette rewind 
the tape to the beginning of this program. 

4 Reload the original packer and RUN the program. When asked for 
the name of the program to be packed respond with ‘PACKER2’ 
and the program will load this into memory. 
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5 Watch the packer as it packs the variable names and check that all is 
going well. Expect it to take a long time by computer standards; it is 
a complex program. 

6 When it has reduced the program to its minimum size it will ask for a 
name to save the new version under. We suggest always prefixing 
these names with ‘P.’ to distinguish packed versions from the 
originals; so respond with ‘P.PACKER’. This will then be saved to 
disc or tape. 

7 Reload ‘P.PACKER’ and LIST it. It should be very difficult to read 
but it should work properly. Copy the first line and remove the‘*’ in 
front of the ‘HIMEM=&3300’. The star has prevented anything else 
being packed on to this line and therefore it is a simple job, in the 
future, to set the current value of HIMEM to a different one, should 
you wish to. 

8 Test this new version using the short test program given above and 
check the result against the specimen printed. 


At the end of this process you should have a short packing program (under 
4K) which will reduce all the programs that you load into it to their minimum 
possible size, without introducing bugs to them. 

If, for some reason, there is a line or lines in one of your programs which 
you don’t want to be packed, place an asterisk (‘*’) at the beginning of the 
line(s) and resave the program for loading into the packer. Then, when 
packed, the asterisk can be removed, using the cursor and copy keys, and the 
program should still work perfectly with the line you protected not being 
followed by any other code on the same line. 

We hope that all this talk hasn’t put you off typing in this program, for it is a 
most valuable tool and well worth the effort. You will also need it later, as 
some of the programs won’t run in their normal version but must be packed 
first. Anyone who really wants to know how it works can try to follow the logic 
using the various clues held in the variable names. There are a number of 
checks to be performed for all kinds of allowable BASIC syntax, and you can 
then take the appropriate action to pack them correctly. Remember that 
packing a program leaves it so that it cannot be edited afterwards. So always 
keep the original, unpacked version very carefully. 
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In this chapter we want to show how the modules in the previous two 
chapters can be combined into simple educational programs. These programs 
are not necessarily simple in their aims or objectives, but they should be easy 
to follow and make the use of our programming modules quite clear. Besides 
providing two working programs written to the educational and programming 
specifications given earlier, they may also provide you with ideas for your 
own programs and perhaps even leave you with the feeling that you can do 
better. This is precisely the effect we want the programs to have on you. They 
are simple in appearance, programming and concept but they show how 
satisfactory educational programs can be written with a minimum of 
programming effort, by the use of good structure and modular approach. 

Both programs will be fully documented, routine by routine, as they are 
listed. To save repetition, the standard modules are not reprinted here; you 
will need to add these either before or after the rest of the program has been 
typed. Full details of how to add the modules to your programs are given in 
Appendix 3. 


‘Times table’ test 


The rationale behind this program is fully explained in Chapter 3, so refer to 
that section for details about its purpose and aim. Notice the use of discrete 
line numbers for each module. This makes alteration simple as each part is 
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easy to find and separate. To type these in using the same line numbers use 
the AUTO command followed by the first line number of each program 
section. Only RENUMBER at the very end, otherwise typing mistakes will be 
much harder to find! 


Figure 7.1 


10 REM TIMES TABLES FINAL VERSION 
20 ON ERROR GOTOUS20O4 


Not too difficult to understand what is going on here! The REM is simply a 
title and the ON ERROR line takes us into the debugging module if an error is 
found or ESCAPE is pressed. 


Figure 7.2 

140 MODE4 

200 PROCinit 

500 PROCintro 

40@ FROCsetupoptions 
240 PROCrungame 

602@ PROCdisplayscores 
700 FROCanothergo 

800 END 


This is the main program loop and shows the structure at its simplest level. 
After initialization (PROCinit) we introduce the program (PROCintro) and 
then set up the various playing and output options (PROCsetupoptions). The 
actual game loop is contained entirely within PROCrungame and after ten 
questions this passes control to PROCdisplayscores. The option of another go 
is given in PROCanothergo and only if this is refused does execution reach 
the END on line 800. 


Figure 7.3 

1000 DEFPROCintro 

1@21@ CLS | 

1020 FROCcol ourchange (1, YELLOW) 
1930 PROCcol ourchange (@, BLUE) 
1440 FPRINTTAB(S,@)s; 


1130 


114@ 
1156 


1168 
1170 
1180 


1190 
1200 
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PROCquadruple("Times Tables") 
PRINTTAB(12,5) 5 


PROCdouble ("Instructions") 


PROCcentre(1@0,"In this program 
you have to try to",!1) 
PROCcentre(11,"“answer 10 table 
problems correctly.",1) 
PROCcentre(14,"All you need to 
do is type the correct",1) 
FROCcentre(iS,"numbers and then 
press the RETURN key",1) 
PROCcentre(18, "Remember you can 
correct any mistake" ,1) 
PROCcentre(19, "before you press 
RETURN by pressing",1) 
PROCcentre(20,"the DELETE key.",1) 
PROCcentre(23,"Before we start 
you need to get someone",1) 
PROCcentre(24,"to set up the 
levels and options.",1) 
PROCcentre(29,"Press the 
to carry on.",1) 
REFEAT 

UNTILFNyn 
ENDPROC 


"Y° key 


This is a short introduction to the program and its operation. To make the 
screen attractive to read, extensive use is made of the display modules 


PROCquadruple, 
used to move the curs 


PROCdouble and PROCcentre. The PRINT TAB lines are 
usorto th correct point to centre the large-sized character 


routines. These weré calculated using the following formulae: 


Key 
no = Number of characters per line in the mode that you are 
using. 
length = _ Thelength of the string that you want to centre. 
column = The x co-ordinate position to be used in the TAB 
statement. 
PROCdouble column=(no) — length (length/2) 
PROCquadruple column=(no/2)—length 


It would be simple to write a centring function for these typefaces, but using 
the formula in your head is also simple enough. 
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The only other routine called from this procedure is FNyn which halts 
execution until the ‘y’ key is pressed. 


Figure 7.4 


1500 DEFPROCinit 
15190 PROCcol our 
1520 PROCcof f 
1530 sounds=@ 
13540 ENDPROC 


Another simple routine which sets up all the variables needed by other 
parts of the program. The call to PROCcolour enables us to use names 
instead of numbers in future colour commands. The cursor is turned off in 
PROCcoff and the sound flag is set to zero to stop all sound unless it is reset 


by the user in one of the options. 


Figure 7.5 


2400 
2016 
2020 
2630 
29406 
24350 
2060 
28706 


2086 


2090 
21040 
2110 
2120 
2130 
2148 
2150 


21460 
2170 


DEFPROCsetupoptions 

LOCAL 

PROCcol ourchange (1, BLUE) 
PROCcol our change (@, YELLOW) 
CLS 

PRINTTAB(13,@) 5 
PROCquadruple ("Options") 
PROCcentre(S,"Do you wish to 
have sound ?",1) 
PROCcentre (6, "Press 
or ‘N‘ for No.",1) 
PRINTTAB(19,7)3 
PROCcon 

sound/Z=FNyn 
PROCcof t¢ 
PROCtwindow (0,5,40,5,0) 

VDU26 

PROCcentre(s,"This program can 
test up to the",1) 
PROCcentre(6,"999 table !'",1) 
PROCcentre(8,"What is the largest 
table you",1) 


"Y¥Y’ for Yes 
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PROCcentre(9,"wish to test?",1) 
PRINTTAB(@,11) “Type this number 
now “8 

Llimit%#=FNnumeric (3,0) 
PROCtwindow(@,4,40,11,@) 

VDU2S 

PROCcentre(3,”"Do you wish to 
Print out each childs",1) 
PROCcentre(4&,"result at the end 
of the session 7",1) 
PROCcentre(7,"Press ‘Y’ for Yes 
or ‘N°’ for No.",1) 
PRINTTAB(19,8)3 

PROCcon 

printer Z=FNyn 

PROCcof f 

PROCtwindow (6,5,40,10,0) 

VDU2ZS 

IF (printerZ AND FNprinteron) 

OR (NOT printerZ) ENDPROC 
PROCcol1 our change (@, BLACK+FLASH) 
PRINTTAB(@,4) 3; 

PROCdouble ("The printer isn’t 
switched on or") 

PROCdouble ("it isn’t working!") 
PROCcentre(1@0,"Please either 
correct this and then",1) 


PROCcentre(11,"press ‘Y° or press 


"N° if you wish",1) 
PROCcentre(1i2,"to change your 
mind about the printer.",1) 
PROCcon 

PRINTTAB(19,13)5 

printer AZ=FNyn 

PROCcof f 

IF NOT printer% ENDPROC 
PROCcof f 
PROCcol1 our change (@, YELLOW) 
GOTO2210 
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Although this is quite a long procedure its only function is to get answers to 
three questions. Lines 2050 to 2110 ask about sound; lines 2150 to 2200 are 
used to set the upper limit for the tables to be presented; and lines 2230 to 
2280 ask if a printout of results is required. The last lines of the procedure are 
used to stop the program trying to print to a non-existent or non-functioning 
printer. They cannot be exited if there is any chance that the printer will cause 
the program to ‘hang up’, and will keep on asking the questions until this is 
assured. This procedure could have been three separate routines but there is 
a space saving by writing them into just one. 

You might have noticed the LOCAL on line 2010 which actually does 
nothing at all. It is there by virtue of a deliberate mistake and to illustrate one 
method of procedure writing. When we write a procedure, the line that calls it 
is always followed by a line reading LOCAL. This is to remind us that we 
should define as LOCAL all those variables not needed by another procedure 
or program part. Then when the procedure is complete we type in the names 
of the LOCAL variables; parameters mustn't be included in the list — they are 
local by definition. In the case of this procedure there aren’t any LOCAL 
variables at all and so the line is redundant and could be removed, but then 
we wouldn’t have been able to explain all this, so we deliberately left it there. 


Figure 7.6 


2340 DEFPROCrungame 

221@ LOCALquestnumberZ% 

232280 questnumber “~=8 

2o086 right“=0 

2946 wrong~=0 

2uo8 FPROCname 

23960 REPEAT 

2u/® questnumber 4=questnumber ~+1 
2288 PROCquestion 

23990 UNT ILquestnumber 2=10 
2600 ENDPROC 


This is the main program loop and all that it does is to set up the counters, 
one for the number of questions, one for the number correct and one for 
those that were answered incorrectly. Then the name of the child is found 
using PROCname. The REPEAT/UNTIL loop ensures that just ten questions 
are asked before the results are printed out, on screen or printer. 
PROCquestion is called on each of the ten occasions. 
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Figure 7.7 


2/700 
2/716 
2720 
2758 
2746 
2750 
2/66 


2770 


2/786 
2798 


2800 
2810 
2820 
28208 
2840 
2850 
29860 
2878 
23808 
2890 


DEFPROCname 

LOCAL welcome? 

CLS 
PROCcoi our change (@, YELLOW) 
PROCcol ourchange (1 ,MAGENTA) 
PRINTTAB(O,8&)s 
PROCquadruple("What is your 
name ?") 
PROCcentre(12,"“Type your name 
now and then press RETURN"”,1) 
PRINTTAB(15,14)5 
namet=FNgpinput (10,4, 
FNrange("a..z")) 

CLS 

PROCcircle(1150,100,75,1) 
PROCcircie(100,900,75,1) 
PROCpoly (7,100,100,75,1) 
PROCpoly (5,1150,900,75,1) 
welcomes="Welcome "+namet 


PRINTTAB (19-LEN (welcomes) ,15); 


PROCquadrupl e (welcome?) 
PROCdelay (3) 
ENDPROC 
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The bulk of this procedure is taken up with the appearance of the screen. If 
you wanted to reduce it to its minimum there would be just three lines (2770 
to 2790), but as this is the first screen to be presented to the child it is worth 
spending time and code making it attractive and interesting. The call to 
PROCdelay is for three seconds but can be changed to any value that you 
desire, or could be omitted if you so wish. 
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35000 
3016 


30208 


3030 
35646 


DEFPROCquestion 


LOCALfirstnumber%,secondnumber 4, 


answer 2Z,wrongtflagZ% 
firstnumber Z=RND (limit) 
secondnumber Z=RND (limits) 
answer Z=firstnumberZ% 
*#secondnumber “4 
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2450 wrongflag“~=6 

=4658 PROCdisplayquestion 

3070 PROCcheckanswer 

38980 ENDFPROC 


This is where the answer for the question to be set is calculated from two 
random numbers. The ‘wrongflag%’, which is used to check how many times 
you have got the question wrong, is set to zero as you would expect. Don’t 
confuse this with ‘wrong%’, which counts the number of questions you 
answered wrongly, not the number of times you have got a single question 
wrong. This means that when the results are printed out the numbers may 
add up to more than 10. There are separate routines to display the question 


and to check the answers, so they are called here. 


Figure 7.9 


3306 
5301G 
2u28 
3038 
5346 
Soe 


2068 
3so/7@ 
Sue 
Rider 471) 
5600 
56108 
3620 
3636 
35646 


2650 


DEFPROCdi spl ayquestion 
VDU26,12 

PROCcol ourchange (1,RED) 

PROCcol ourchange (@, BLUE) 
PRINTTABR(9,@)5 

PROCquadruple ("Question " 

+STR# (questnumberZ) ) 

PRINTTAB (C19—-LEN (name?) ,3)35 
PROCquadruple (name) 
PRINTTAB(S,7)s 

PROCdouble ("What is the answer 
to :") : 

questi ons=STRS (firstnumber 7) 

+" » #“"+STRS (secondnumber/Z)+" = " 
PRINTTAB (20—-LEN (question?) ,12)5 
PROCquadruple (question) 
PRINTTAB(@,15) "Type your answer 
now "3 

try4Z=F Nnumeric (LEN (STR 
(answer Z)) ,@) 

ENDPROC 
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Just as with PROCname, the bulk of this procedure is screen formatting 
and appearance code; none of it is essential yet all of it helps to lift the 
program above the level of ordinary. The child’s response to the question is 
input on line 3640 using FNnumeric. Notice that the parameter used for 
length of input is set to be the length of the answer; this stops silly answers 
being given but might give a clue to an older child and could be set to a fixed 
length if required — make the length long enough for the biggest possible 


answer; we suggest ten characters. 


Figure 7.10 


5808 
35816 


3826 


Not much code in this routine but here the try is checked against the 


DEFPROCcheckanswer 

IF tryZ=answer% PROCright 
ELSE PROCwrong 

ENDPROC 


answer and appropriate action is taken. 
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DEFPROCright 

LOCALcolourZ 
right4#=rightA~+1 

PROCd1i splayanswer 
PROCgwindow (@,16,40,15,0) 
GCOLG@,1 

PROCcircle (640,300,200, TRUE) 
GCOLO,@ 

PROCpol y (RND (7) 43,640,300, 200, 
TRUE) 

VDU26 

PRINTTAB(15,21)5 
PROCquadruple ("Right") 
PRINTTAB (19—LEN (name) , 24) 5 
PROCquadruple (name?) 


4140 FORcolourZ=0 TOIS 

4150 *¥FX1I9 

4156 PROCcol ourchange (@,colour 2) 
4176 IF sound% SOUND 1,-15, 


colour 4Z#15,3 
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4180 PROCdelay(.2) 
4199 NEXT 

4200 PROCdelay (3) 
4210 ENDPROC 


This routine uses sound, colour and a little graphic plotting to announce a 
correct answer. Only correct answers are ever printed on the screen in this 
way, by using PROCdisplayanswer. The aim of the program is to test, but we 
should use every opportunity to reinforce learning, and so never give a child a 
chance to learn the wrong answer by printing it out. The correct answer is 
what needs to be learned. The child’s name is printed for two reasons: firstly it 
helps emphasize that they have got a right answer, and secondly it tries to 
make the machine appear more friendly to the child. There is another 
optional delay at the end of this procedure. 


Figure 7.12 

4400 DEFPROCd1 spl ayanswer 

44180 PROCtwindow (0,3,40,13,0) 

4420 questi on#=questi ons+STirR$ (answer 24) 
4430 PRINTTAB (2@6—LEN (question?) ,35)5 
4440 PROCquadruple (questions) 

44230 ENDPROC 


The answer is always displayed with the question, because we are trying to 
teach the child that they are connected by the table involved. PROCtwindow 
is used here not for its window effect but simply to clear the screen, or to be 
more exact that part of the screen that the window covers. On line 4430, 
because we don’t know how long the string to be printed is, we have 
programmed the formula given above to centre the double-width and -height 
text. 


Figure 7.13 


4900 DEFPROCdel ay (time) 

491@ LOCALnowz 

4920 nowA=TIME 

4930 REPEAT 

4740 UNTILTIME—-nowZA+time*140 
4935@ ENDPROC 
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There are many ways to produce a delay in programs. You might use an 
INKEY or INKEY$ statement which will terminate the delay if a key is 
pressed. Others might use a FOR/NEXT loop to introduce a delay, but here 
we use the internal clock to count down a genuine timed delay. The delay can 
vary from one hundredth of a second to many minutes and the time delay 
that we require is passed to the procedure, as a parameter, in seconds or 
fractions of a second. You might think that using the internal timer in this way 
could preclude its use for other timing purposes, but with the construction 
given here there is no need to zero the timer; therefore other parts of the 
program can use it without any ill effects. If you want to be able to fine-tune a 
delay, this is the type of structure to use; it is very flexible and fairly accurate. 


Figure 7.14 

240@ DEFPROCwrong 

99010 wrong4=wrongAtl 

9020 wrongflag“=wrongflagAéti 

2030 IFwrongflag“Z=2 FROCgi veup: ENDPROC 

27440 PROCtwindow(0,3,40,14,@) 

2950 PRINTTAB(14,4);5 

2466 PROCquadruple("Wrong!") 

2078 PRINTTAB(19—LEN (name?) ,8); 

248% PROCquadruple (name?) 

2090 FRINTTAB(2,11)5 

9100 FROCdouble("Why don‘t you try 
that one again !") 

211@ FROCdelay (2) 

9120 PROCdisplayquestion 

9130 FROCcCheckanswer 

314@ ENDFROC 


At the beginning of the procedure you can see the code with which we can 
allow more than one try at each problem but set a limit to the number of 
wrong attempts that are to be made. We use wrongflag% to count the 
number of times a certain problem has been answered wrongly; by testing 
this at the beginning of this procedure we can branch to a procedure that ends 
the presentation of this problem and leads to another. Line 5030 contains the 
test. If the child has typed a wrong answer twice the execution passes to 
PROCgiveup. This means that we could set the limit to any value, but too 
high a level is likely to frustrate the child. 

The rest of this procedure gives feedback about the wrong answer - it is not 
emphasized by being displayed — and then allows another attempt by 
branching to PROCdisplayquestion and PROC checkanswer. 
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32006 DEFPROCg1 veup 

3214 CLS 

S220 PROCcentre(3,"Lets give that 
one a miss now.",1) 
PFROCcentre(S5,"The answer was : 
PROCdelay (3) 
FROCdi spl ayanswer 
PROCdelay (3) 

ENDPROC 


3220 
3240 
328 
7260 
22/8 


"0 71) 


As explained above, if the child has got the question wrong twice then we 
give up on this question and tell them what the right answer is. This is done 
using PROCdisplayanswer as before. It would have been easy to put this 
code into the PROCright routine. But by writing it as a separate procedure we 
can call it from two different procedures and therefore save some memory 


space by not having the same piece of code twice. 


Figure 7.16 


7400 
781@ 
7020 
7036 
7040 
70350 
7668 


7070 
708@ 
70990 


7106 
7110 
7120 


7130 
7140 


71350 
7160 
717@ 


DEFPROCdisplayscores 
VDU26,12 
FPROCcol] our change (@, GREEN) 
PROCcol our change (1, BLUE) 
PRINTTAB(8,@) ; 
PROCquadruple ("Final Scores") 
FROCcentre(s,"The final scores 
for the 10 questions",1) 
PROCcentre(é,"are :",1) 
PRINTTAB(S,9) $s 
PROCquadruple (STRS (rightZ) 
+" problems right") 
PROCcentre(13,"and",1) 
PRINTTAB(3,16) 5 
PROCquadruple (STR (wrong?) 
+" problems wrong.") 
IF printer’Z PROCprintout 
PROCcentre(3@,"Press the 
key to continue",1) 
REPEAT 

UNTIL FNyn 
ENDPROC 


“y¥’ 


Two Simple Educational Programs 147 


At the end of ten questions the scores are printed out on screen, always, 
and on a printer if this has been selected. There is another of those deliberate 
mistakes here too! The use of FNprinteron was recommended before each 
and every command to print something out; here we have simply used it at 
the time of selection to check the printer. If anything has happened to the 
printer in the meantime to stop it working, e.g. it has been switched off, or 
offline has been selected, then the machine will ‘hang up’ at this point in the 
program. We should have tested the printer at this point too and either issued 
a warning or simply branched out of the printout routine if it wasn’t going to 
work. There are two possible ways of coding the abort situation. Line 7130 
could be changed to read: 


7130 IF printer% AND FNprinteron THEN PROCprintout. 


Alternatively it could be included in the printout procedure itself using this 
code: 


7505 IF NOT FNprinteron THEN ENDPROC 


The former is probably better as it stops us even branching to PROCprintout, 
but that is a matter of style. The program is more robust with this extra check 
and we recommend that you use one of these revised lines with the program. 


Figure 7.17 

79060 DEFPROCprintout 

73510 #*#FX3,10. 

73520 PRINTnamets3" scored :""° 

70O3@ PRINTright%3" problems correct 
(first or second attempt)."*’ 

7340 PRINTwrong4;" problems wrong 
(first or second attempt).”"’* 

75350 PRINTSTRING$S (30,"#") °° 

73960 *#FX3,0@ 

737@ ENDPROC 


This is a very simple printout routine which used the output selection code 
in the operating system, line 7510, rather than the more usual VDU 2 
command. VDU 2 prints out anything that appears on screen but that would 
corrupt the display that is already on the screen. To prevent this we select that 
future output goes only to the printer and then PRINT the information. So we 
must reset the output flow after the call, and this is done on line 7560. 
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Figure 7.18 


B00 
8010 
8020 
8430 
B46 
8450 


B3a46G 


807@ 
ROBO 
BOT 


8100 
8110 
8120 
Biz0 


8140 
8150 
8166 
8170 
8180 
8190 


DEFPROCanothergoa 

VDU2Z6,12 

FROCcol our change (@,MAGENTA) 
PROCcol ourchange (1, YELLOW) 
FRINTTAB(1,=) $5 
PROCdouble("Would you like to 
try the game again *’") 
PROCcentre(S,"Fress ‘Y' 
or ‘“N’ for No",1) 
PRINTTAB(19,1@) 5 
PROCcon 

IF FNyn PROCcof f :PROCrungame 

: ENDPROC 

VDU2Z6,12 

PROCcof f 

PRINTTAB (4,4); 

PROCdouble("Thank you for playing 
this game") 

PRINTTAB(13,15) 35 
PROCquadruplet("Bye Bye”) 
PROCdelay (1@) 

CLEAR 

VDU 26,12 

ENDPROC 


for Yes 


It is in this procedure that the logic of putting the main game loop into a 
procedure becomes apparent. By doing so we can call the game from two 
separate places in the program. If you select to play another game, for either 
the same or another child, execution passes back to PROCrungame. By 
doing so it bypasses the option-setting procedure and plays a second game 
with the same options and levels. It does ask for another player's name, 
however. 

If you decide not to have another go, a ‘Bye Bye’ message is output and 
the screen is cleared before the ENDPROC statement passes ‘control back to 
line 800 and the END is executed. 

This program is not complete with just the code above. You need to add to 
it all the modules, which you typed in from the previous chapters, listed 
below. These procedures may be added at any time during the process of 
typing the program, but we would suggest that you start by adding them. This 
means that you can test each of the routines given above as you type them in 
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from the book. If you add the procedures afterwards then you can test the 
program only when it is all typed in, and you are likely to have more bugs at 
this stage than if you had tested each part as it was typed. If you saved the 
library routines as advised in Appendix 3, i.e. as ASCII files, then it is 
simplicity itself to add them to your program using the *EXEC command. 

The routines that you need are: 


Figure 7.19 
Start Routine name 
Line 


104600 FNprinteron 
11606 PROCcentre 
120800 PROCcoff 
12610 PROCcon 

13@8Q0 PROCdouble 
135860 PROCquadruple 
14000 PROCgwindow 
143500 PROCtwindow 
15000 FPROCcircle 
15500 PROCpoly 
15006 PROCcolourchange 
17@0@ PROCcolour 
20066 FNgpinput 
2i4@@0 FNnumeric 
22466 FNyn 

52000 jcError Routine 
32206 PROCdebugkeys 


We hope it is evident that this program, although not of any earth- 
shattering educational value, is a vast improvement upon the original 
program as printed in Chapter 2. It isn’t perfect by any means, few programs 
ever are, but we hope that it gives you a chance to see how an idea can be 
turned into a program. We also hope that you can see how you would like to 
change it for your own use and how simple this is to achieve due to the 
structure the program follows. 

As this is a demonstration of the programming modules, we have used 
rather more of them than we would do normally. For example, it is a 
complete waste of memory to use both PROCcircle and PROCpoly in the 
same program. If you wanted to make this program more attractive visually 
this would be possible by using a different mode with more colours. It is 
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simple to modify this program to work in mode 1 if you are prepared to use a 
packed version. Experiment with this and all the other programs in the book 
until they come to suit your desires and your purpose. It is one of the ways 
you can learn new techniques and develop your own style. 


“Save man’ game 


As a contrast to the previous game, here is one which can easily be tailored to 
your own needs and wishes simply by the addition of your own DATA. It 
might be termed ‘context free’ by some program writers but it isn’t really a 
good example of a context-free program. It is based on the idea of Hangman; 
there are hundreds of versions of that available for every computer, but with 
additions and changes made, in the main, for educational reasons. 

The first change is that the words can all have clues attached to them. The 
program is thus much more suitable for the learning of spellings, if you give a 
context clue, or for foreign languages, where you might give an English word 
as a clue to the answer. It could be used in any situation where words, their 
spelling and even their meanings need to be learned by rote and then tested. 

The second change is that there is none of this violent ‘hanging’ of 
individuals if they make too many mistakes. We are fully aware that such 
things are the delight of children the world over but there is no need for us to 
encourage that delight when we are trying to teach or to test some item of 
educational knowledge. In this game we have an unfortunate person who has 
accidentally been bricked up behind a number of walls. He fell asleep while 
his workmates carried on working! Because the cement is still wet he needs 
only a small chisel to be able to get through each wall, but the chisels available 
are good for only one wall at a time before they become too blunt to use. This 
means that it is essential that a steady supply of chisels is sent down to the 
poor chap. The user’s task is to keep guessing the letters that make up the 
word problem, and for every one that fits the word an extra chisel is sent to 
our hero. When the word is completed the chisel sent down is of a new 
hardened variety and he is able to get right out of the building and revels in 
his freedom again. 

As suggested earlier, before the program was written we considered 
carefully the various options open to us as we designed the program. It would 
be far too boring, and lengthy, to give full details of all the design criteria that 
we specified, many of them being quite obvious. So only those of most 
interest are detailed here. The other features are made clear in the listing and 
its documentation. 

One of these design criteria was the use of clues as a help or prompt to the 
child. Because these were of such importance to the original concept we 
decided to give them the most prominent position on screen at all times. For 
the program to be of more general use we included a no-clue option, and this 
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was built into the design of the DATA statements. The use of clues is therefore 
in the hands of the person who adds the DATA statements to the main 
program. 

A further, detailed design criterion was the need for the program input not 
to accept any letters that had already been checked against the word given. 
This means that there is an ever-decreasing number of letters acceptable as 
input. This is surprisingly simple to implement due to the design of the 
general-purpose input function included in the standard modules. One of the 
parameters is a string containing all the valid letters; all character input that 
isn’t included in this string is rejected. Therefore all that needs to be done is 
for another function to remove each letter from the alphabet string as it is 
used. 

A final design criteria worthy of mention is the method of DATA entry. This 
should be as simple as possible, so that the program can be easily modified to 
different needs and situations. If this type of consideration is made at the 
design stage it can save a great deal of reprogramming later. We well recall 
one particular program which instead of using DATA statements, in the way 
that we would suggest, was composed entirely of ‘IF zzz = yyy OR IF zzx = 
yyy OR IF zxx = yyy THEN PRINT yyy’ statements. Not only was this an 
incredible waste of memory space, it also meant that modifying or adding to 
the program’s range of options was very difficult. 

We started by deciding what information we needed from the DATA 
statements in order to run the game. This came down to just two items: the 
text of the clue and the word in the answer. We also need to know when we 
have run out of words and if the user doesn’t want clues printed. It should be 
easy to use a simple test to check for each of these situations. The obvious 
way to check for the end of the DATA is to check for null strings, i.e. strings of 
zero length. So we need to end our DATA with a line containing ‘DATA “ ”, “ ”. 
The two pairs of quotes mean that the READ statement won’t return an ‘Out 
of DATA’ error but will contain null strings. By testing for two such null strings 
we can branch out of the loop because there is no further DATA. In a very 
similar way we could use the absence of a clue string to signal that we have 
not to print a clue at all. All the user needs do is put a null string in place of the 
clue string, and no clue or prompt will be printed. So a line that reads ‘DATA 
“This is a clue”,“clue’” will cause the heading and the clue itself to be printed, 
whereas one reading ‘DATA “ ”’, “clue’” would omit those print statements. 

Once again the purpose is to demonstrate the way that the various modules 
can be used in a simple program. There has been no attempt to cut the 
modules down in size or remove redundant code. You may wish to do so 
yourself, or might like to use the program in a packed state. If you choose to 
do so you are likely to be able to use the extra space to change the screen 
mode to mode 1 and therefore gain a couple more colours. 
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Figure 7.20 
16 REM Save Man Game 
24 ON ERROR GOTO 32000 


These lines should be left in during debugging, but if you intend to pack the 
finished, debugged version, remove them and all lines above 32000. 


Figure 7.21 


100 MODE4 

116 PROCinit 

1260 PROCget_name 

13@ REPEAT 

140 PROCnew_word 

1i3@ UNTILend of gamez 
166 PROCend_game 

1706 END 


Main program calls are, as usual, all below 990 in line number. Using mode 
4 restricts us to only two colours but it gives a pleasant typeface to work with, 
so much better for children than the mode 2 or 5 typeface. PROCinit is used 
for program initialization procedures, as normal. In this program, however, 
there is a need to initialize certain variables before each new word, so a 
second initialization routine is provided later. We find the child’s name to 
make the program more ‘user friendly’, then we enter the main program 
loop. This presents each word until the “‘end_of_game%’ flag is set to TRUE, 
when the game-ending procedure starts. 


Figure 7.22 

10606 DEFPROCinit 

191@ VDU23,225,56,92,76,100,112,120, 
124,124 

1020 VDU23,226,124,108,108,108,198, 
198,198,0 

10930 VDU23,227,0,48,56,116,120,112, 
120,48 

1949 VDU2Z3,228,48,108,1098,109,108, 
198,108,108 

1050 VDU23, 229, 124,56,56,56,56,56,56,08 


1060 


1070 


1080 
1869@ 
11408 
1110 
1120 
1130 
1140 


115@ 
1160 
1176 
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VDU2S, 230,253,253, 2535,08,223,223, 


223,08 


VDU2S , 231,255,253, 2535,0,2235,225, 


2235,@ 

RESTORES@OO 
mani¢t=FNread string (6) 
man2$=FNread string (6) 
wipet=FNread string (6) 
end of gameZ=FALSE 


£3 9or $=STRINGS (18, CHR#230+CHRF23 1) 


tall $=STRINGS (6, CHRS230+CHRES 
+CHR? 10) 

PROCcoff 

RESTORE?S10 

ENDPROC 
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The bulk of this procedure is needed to set up the graphics for later. The 
VDU 23 statements are used to define the little man character and the bricks 
of the prison. The calls to FNread_string set the strings to be used to print the 
whole of the man in one print statement. The RESTORE 8000 ensures that 
we are reading the correct area of DATA in FNread_string. We will need to 
wipe our little man off the screen, so a string to do this is also READ from 
DATA statements. Then the rest of the global variables are initialized, the 
cursor is turned off and the DATA pointer set to the start of our word list, line 


9510. 

Figure 7.23 

1300 DEFPROCget_name 

1316 PROCcolourchange (@,5) 

1320 PROCcolourchange(1,3) 

13206 CLS 

1240 PRINTTAB(@O,8)s; 

1250 PROCquadruple("What is your 
name ?") 

1360 PROCcentre(12,"Type your name 
now and then press RETURN" ,1) 

1370 PRINTTAB(15,14); 

1380 namet=FNgpinput (10,4,FNrange 
("a..z") ) 

1390 CLS 
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1440 hellos="Hello “+names 

1410 PRINTTAB(19—-LEN (hello?) ,15)5 
1426 PROCgquadruple (hello?) 

143@ PROCdelay (3) 

1440 ENDPROC 


This procedure is virtually identical to the one in the last program and 
illustrates the idea of developing your own library of useful routines. This one 
works well in MODE 4, and MODE 1, so why not use it in a few programs? It 
saves extra programming time and makes life a little simpler. Try to avoid all 
your programs looking alike or the user is likely to be bored by the sameness 
of it all and start to perform at less than his best. 


Figure 7.24 


1500 DEFPROCnew_word 

151@ READcluest ,wordt? 

1520 IFwords="“"end of gameZ~=TRUE: 
ENDFROC 

1530 FROCword set_up 

154@ PROCprison 

1550 PRINTTAB(18—-LEN (name#) /2,@); 

1560 PROCdouble (name) 

13570 PROCcentre(30,"Save Man Game" ,1) 

1380 IFclue#<>°"PROCprint_clue 

135° answer $=STRINGS (LEN (words),"_ ") 

1606 FROCupdate 

1610 PRINTTAB(S, 25) manlt 

1626 FROCget guess 

163@ ENDPROC 


Each new word is READ from the DATA lines at the beginning of this 
routine and checked to see if they are terminal values. A single test on word$ 
is all that is required and, if found to be a null string, end_of_game% is set to 
be TRUE and the procedure is ended. If there is another word left then the 
second initialization procedure is called, PROCword_set_up. The graphics are 
printed on screen in PROCprison and then the user’s name is printed at the 
top of the screen. After printing the other headings the clue on/off check is 
made. This ensures that if there is no clue there is no heading either; by using 
this construction it is possible to mix words with clues and without them in the 
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same game. This might be useful if you have a group of words all with the 
same general heading which only needs to appear once. The ‘answer$’ 
variable is used to hold the word guessed so far and at this stage is set to be 
equal to the right number of underline characters. PROCupdate prints the 
new valid string on the screen and then the man is printed in his starting 
position. PROCget_guess is the input procedure and is looped around until 
the word is complete. When the word is finished, control is passed back to the 
main program by the ENDPROC on line 1630. The two exits from this 
procedure ensure that we never print the null strings and that the end game 
flag is set if this is the case. 


Figure 7.25 

2000 DEFPROCword set up 
2610 valid#=FNrange("a..z2") 
2020 found_flag“%=0 

2030 man_pos“z=3 

2040 finished _word4=FALSE 
24930 PROCcol ourchange (@,3) 
2960 PROCcolourchange (1,4) 
20760 ENDPROC 


The second initialization of variables is required every time a new word is 
chosen. The string holding the valid characters needs to be set to the whole 
alphabet and because FNrange is part of FNgpinput it makes sense to use that 
code to set the string. No capital letters are included, so if you intend to use 
the program as given here you must not include proper nouns. The remaining 
part of the procedure sets up the flags, found_flag% and finished_word%, 
then changes the colours to reasonable values; these might have to be altered 
by the end of the last word. 


Figure 7.26 

20400 DEFPROCprison 

2914 LOCALcounter< 

29206 CLS 

2530 PRINTTAB(1,23)3floors; TAB(1,28); 
floors 

2240 FORcounter 42=1TOS6STEPS 

2008 PRINTTAB(counter4,23) swallt 

2760 NEXT 

24/70 ENDFROC 
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The ‘prison’ needs to be printed, and it is done by this routine. The method 
used is to print a roof and a floor, then using a loop to print walls five columns 
apart. 


Figure 7.27 


2660 DEFPROCprint_clue 
2414 PRINTTAB(14,4) 5; 


3826 
30306 
3446 
3858 


PROCgquadruple("Clues ") 
PRINTTAB(C19—-LEN (clued) /2,7)5 
PROCdoubleiclues) 

ENDPROC 


If there is a clue to be given it is headed using PROCquadruple and then 
centred on the screen in double-height lettering. If there is no clue, this 
procedure is not called and a large empty space is left. You might prefer there 
to be a standard prompt printed in the space and this is very simple to do. All 
that is required is for you to write a procedure to do the printing, called 
PROCprompt for this example, and then add the following code to the end of 
line 1580: ‘ELSE PROCprompt’. This will ensure that there is always 


something printed in that space. 


Figure 7.28 


5300 
oo18 


3078 


3B 


DEFPROCupdate 

LOCALcounter% 
PRINTTAB (20—-LEN (answer?) ,12); 
PROCquadruple (answer #) 
PRINTTAB(2,19)3"These are the 
letters left :" 
PRINTTAB (46,21) sSPC263 TAB(19—- 
LEN (valid?) /2,21)3; valid? 

IF found _flag% THEN FOR counter%= 
1 TO found _flag%: PROCmove_man: 
NEXT 

IF INSTR (answer?," = ")}=@ THEN 
PROCword end 

ENDPROC 
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This procedure keeps the screen up to date, so that the answer$ is always 
correct and the valid$ is always printed in full. The SPC on line 3550 is used 
to print twenty-six spaces, i.e. to wipe out the old string, before the new one is 
centred on screen. If there has been a letter found then we need to move the 
man along a little. Don’t forget that if a letter occurs more than once we need to 
move the man through that number of walls too. In order to ensure that this 
happens we use found_flag% in two ways on line 3560. It is firstly used as a 
logical variable, i.e. tested to see if it is TRUE (any non-zero value) or 
FALSE, and then used as the limit for the loop. If no letter has been found, 
the loop is never executed; if one or more have been found, the loop moves 
the man by the number held in found_flag%. By understanding the way that 
BASIC, or to be exact BBC BASIC, understands such things as TRUE and 
FALSE we have saved an amount of code and possibly even an extra 
variable here. The final line of this routine checks to see if there are any 
underline characters in the answer$. If there are, there are still some letters to 
find; if not, the word is complete and we can branch to the PROCword_end 
code. | 


Figure 7.29 


3700 DEFPROCget guess 

571@ REPEAT 

3728 PROCcentre(16,"Press the next 
letter now '",1) 

5738 PRINTTAB(19,17)3; 

3748 PROCcon 

3730 gquess#=FNgpinput (1,1,valid#) 

37608 PROCcof f 

3778 PRINTTAB(@,16) SPC79 

3780 PROCcheck guess 

3798 valid#=FNremove_char (quess#) 

5800 PROCupdate 

381@ UNTILFinished_ word4=TRUE 

$820 ENDPROC 


The loop that we go around for each word is from 3710 to 3810. Within 
this is the input of each letter to be tried, the checking of the letter, its removal 
from the valid$ and the check to see if the word is complete. As an indication 
of the need to enter a guess the cursor is turned on at line 3740 and off again 
after input, line 3760. As the valid$ is adjusted after each guess, only letters 
that haven’t been tried before get through to line 3780, all others being 
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rejected by the general-purpose input routine. This means that we can check 
them and remove them from the valid$ without any need to test them for 
validity within this procedure. The effect of line 3770 could have been 
achieved by any one of a number of techniques, windows included, but to 
remove just two lines of text printing 79 spaces seems the simplest (using 80 
might have caused a scroll, if we printed them up to the bottom line of a 
window, so 79 is safer). The screen update routine is called within this 
procedure after every guess, another example of structure allowing us to write 
less code. 


Figure 7.30 

4000 DEFPROCcheck_quess 

4014 LOCAL 

4020 counter Z2=-¢ 

4620 found flag4=@ 

4046 REPEAT 

4030 counter 4=counter A+1 

47460 IFMIDS (words ,counter~Z,1)=quess? 
found flag’ = found _flagAétl: 
answer $=LEFT? (answer, 
(counter 4-1) #2) +quess#+ 
" “+RIGHTS (answers, 
LEN (answer +?) -—counterZ%#2) So 

44@7@ UNTILcounter%=LEN (word) ~ 

+486 ENDFPROC 


The basic checking algorithm works as follows. We need to scan every 
position within the word for the letter guessed, so a loop is required. If.the 
letter is found then the found_flag% must be incremented and the letter 
inserted in the answer$ at the correct position. The scan needs to continue in 
case the letter occurs twice until we reach the end of the word. The only 
complex part of this routine is the insertion of the letter into answer$. This 
would have been much simpler if we weren’t using a space between each 
letter of the word$ in the answer$. The routine works by taking the first part of 
the string up to the letter, adding in the letter and then finally joining on the 
last part of the string. The calculation is to find the correct position due to the 
spaces. This is a good example of string manipulation and shows what can be 
done, very simply, if you go about the task of programming in a logical 
manner. 
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Figure 7.31 


45060 DEFPROCmove_man 
4516 LOCAL 
4526 FORman_xZ=man_posz TO 
man poszt4STErP2 
45308 PRINTTAB (man_xA4-1,25) swipes 
4S 40 PRINTTAB (man_x4,25) 5;manit 
4550 SOUND® ,—-15,5,2 
43560 PROCdelay(.3) 
4570 PRINTTAB (man_x4,25) ; wipe? 
43584 PRINTTAB (man_x4+1,25) 5 man2s 
459 SOUND@ ,-15,5,2 
4606 FPROCdelay(.3) 
4616 NEXT 
4626 man_pos“Z=man_xA%-1 
4630 ENDPROC 


This procedure moves the man through just one wall and is called more 
than once if there is more than one occurrence of the guessed letter in the 
word. The way that we make the man walk is to print a man with his legs 
closed in one position and then wipe this out and replace it with a man with 
his legs open in the next position on the x axis. By introducing a slight delay 
(three-tenths of a second) between the print statements we can make him 
walk rather than run. The sound is meant to simulate a chisel and occurs 
whilst the man walks from one position to another. We need to remember the 
new position of the man so that we know where he is next time we want to 
move him, and this is assigned to a variable on line 4620. Notice the —1 at the 
end of this line, which is because loop variables are always one greater than 
the limit value on exiting the loop. 


Figure 7.32 


9000 DEFPROCword_ end 

9010 LOCALmoves_left%,counter2Z,colourdZ 

2020 finished _wordZ=TRUE 

0026 moves_left%=(37-—man_pos%Z) /4 

20480 IFmoves_left%“%>@ THEN FOR 
counterZ=1 TOmoves_leftd: 
PROCmove_mans: NEXT 

2054 PROC jump_man 

2060 FORcCo!] our Z=06T07 
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387Q PRGOCcol our change (@,colourd) 
=080 PROCdelay(.5) 

2098 NEXT 

51i#@ PROCdelay (3) 

211@ ENDPROC 


At the end of each word, i.e. when all the letters have been guessed, there 
are certain ‘ends’ of the program to be tidied up and that is the function of.this 
procedure. We first set the finished flag and then we need to find out if the 
man has any more walls to pass through. This is calculated on line 5030 by 
subtracting the current position from 37, the x axis location of finished, and 
dividing by 4 to find the number of moves left — each move takes us four steps 
across the screen. If this number is not equal to zero then we need to move 
him to the end and this is done on line 5040. Once he is at the end of the 
walls we can allow him to jump up and down with joy, so we call 
PROCjump_man. A little colour changing seems in order too so we cycle 
through all the non-flashing colours and wait for three seconds before trying 
to find another word. 


Figure 7.33 

2040 DEFPROCjJump_man 

551@ FORman_y%=25TO21STEP-2 

var pa a PRINTTAB(man_pos2z,man_yAt1) ; 
wipe 

2938 SOUND1 ,—-15,man_y%Z#5,2 

TU44 PRINTTAB (man_pos24,man_yA) s;man2t 

vat barber | PROCdelay(.1) 

var bow fn PRINTTAB (man_posZ,man_yZ) swipes 

wo 7/8 SOUND1 ,-15,man_y4#*5,2 

par eas = {72 PRINTTAB  (man_posi,man_y%-1); 
manit 

2078 PROCdelay(.1) 

3608 NEXT 

3616 FORman_y4=21TO2SSTEFP2 

2620 PRINTTAB (man_posé,man_y4-1)s5 
wipes 

3620 SOUND1 ,—-15,man_yAZ*#5,2 

3546 PRINTTAB  (man_posZ,man_y2Z) ;manls 

2698 PROCdelay(.1) 

2660 PRINTTAB(man_pos4~,man_y2Z) swipes 
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0670 SOUND1 ,—15,man_y4*5,2 

9686 PRINTTAB (man_posZ,man_yAtl1) ; 
man2t 

7596 PROCdelay(.1) 

7780 NEXT 

271@ ENDPROC 


This routine comprises two loops doing the same job except in different 
directions. The first loop makes him jump up the screen and has a negative 
step therefore; the latter makes him move downward again using a positive 
step. By adding sound statements calculated from the position of the man, 
lines 5530, 5570, 5630 and 5670, we get a rather warbling rise and fall in 
tone. 


Figure 7.34 

6000 DEFPROCdelay (time) 

601@ LOCALnow2Z 

6020 nowZ=TIME 

6030 REPEAT UNTIL TIME-nowZ > time*100 
6040 ENDPROC 


The logic of the delay loop should be clear from the last program; notice 
that we don’t reset the timer, so that it can be used for more than one purpose 
at once. The parameter is the delay required in seconds, hence the ‘*100’ on 
line 6030. Notice also how, on this occasion, we have put a REPEAT next to 
its UNTIL. This is perfectly allowable and means that we save a few bytes by 
not using another line number. 


Figure 7.35 

656@ DEFFNremove_char (chr?) 

65140 LOCALposition,left#,right4 

6528 position=INSTR(valids,chr?) 

6530 IFposi tion=@THEN=valids 

6540 IFposi tion=1 THEN=RIGHTS (valids, 
LEN (valid#)-1) 

655@ IFposition=LEN (valid#) THEN=LEFT? 
(valid#,LEN(valid?)-—1) 

6560 left#=LEFT# (valid#,position—I1) 
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63576 right#=RIGHTS (valid#,LEN(valid+) 
—position) 
6380 =left#+right+# 


If we need to remove a character from a string we need to know where it is 
in the string, and this is calculated on line 6520 of this function, by using the 
INSTR function of BASIC. This returns the position of one string within 
another. If you try to think of the string as a long line of letters on a thin piece 
of paper the rest of this explanation should be easy to understand. We are 
using single letters to search the string, so we can cut — or to use the correct 
term ‘slice’ — the string into two parts at the point where the letter occurs, 
remove the letter we don’t want and then rejoin the parts to make the string 
again. 

Before we do this there are three special conditions we need to check for. 
Firstly the letter might not be in the string and we need to send the whole 
string back if that is the case, line 6530. This is never used in this game, 
because an invalid letter is never allowed through to this stage, but we 
thought that this type of string slicing might be of use to you in other 
programs, hence its inclusion here. The second condition is that the letter is 
the first one in the string; this means that all the slicing isn’t required and we 
need just to drop the first letter before returning the string. This can be done 
very simply by using RIGHT$, shown on line 6540. The final exceptional 
condition is that the letter is the last one in the string, in which case we need to 
use LEFT$ to drop this letter off, line 6550. 

Having dealt with all the exceptions the rest of the function carries out the 
slicing described above. The two parts are assigned to variables on lines 6560 
and 6570; the “—1’ on line 6560 ensures that the letter we want to disappear is 
‘cut out’ before the two parts of the string are rejoined and returned to the 
calling procedure on line 6580. 


Figure 7.36 


/@060 DEFPROCend game 

7@206 PROCcCOol ourchangei@,4) 

70630 PROCcol] ourchange(1,7) 

704@ CLS 

7050 PRINTTAB(14,3)s5 

70646 FROCdouble ("Well Done") 

7070 PRINTTAB(19-LEN (name#) , 7); 

7480 PROCquadruple (names) 

749@ PROCcentre(15,"VYou got all the 
words right and",1) 


7100 


7114 
7120 
71230 
7146 
71350 
7160 
7170 
7180 
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PROCcentre(i7,"saved all those 
poor people too '",1) 

RESTORE 97010 

PROCtune (300,1.25) 

CLS 

PRINTTAB(12,12)3 
PROCquadruple("Bye Bye") 
PRINTTAB(19—-LEN (name?) ,15) ; 
PROCguadruple (nameF) 

ENDPROC 
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At the end of a program it is always a good thing to make a bit of a fuss and 
hopefully encourage the child to try again either with this program or another. 
Here we change the screen colours, print a message including the child’s 
name and then play a little tune. Because this program finishes only when all 
the words have been discovered there is little point asking if another go is 
required, so a ‘Bye Bye’ message is also output before control returns to the 
main program and ENDs. The RESTORE on line 7110 ensures that the right 
set of DATA is used to play the tune. The tune is called with a length, i.e. the 
first parameter, of 500, ensuring that it plays to the end. 


Figure 7.37 
8000 REM String Data 


8614 
8020 
802.0 


DATA227 ,8, 10, 225,8,10,226 
DATA227 , 8,10, 228,8,10,279 
DATAS2,8,10,32,89,10,32 


This is needed to set the strings for the graphics. Note the use of cursor 


control codes to move around the screen from the original position. 


Figure 7.38 

9600 REM Tune Data, 1 bar per line 

9410 DATAI21 ,2,121,2,121,2,137,4,121, 
2,149,12 

9020 DATAI21 ,2,121,2,121,2,137,4,121, 
2,129,12 

903@ DATAI21,2,121,2,121,2,137,4,1i21, 


2,149,12 
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9948 DATA149,2,157,2,149,2,141,2,137, 
2,129,2,121,12 
9850 DATAS@Q,@ 


A childish tune turned into numbers for the use of PROCtune. The 
numbers are always in the order: pitch followed by duration; and there is one 
bar per line. This makes it simpler to find a note, when debugging using sheet 
music, if one doesn’t sound quite right. 


Figure 7.39 


75300 REM Word data lines 

9505 REM Word length not above 7 !! 

73510 DATA"Fun with friends.", "games" 

93526 DATA"Great to ride on.","bicycle" 

9530 DATA"Too many hurt your teeth", 
*“sweets" 

9990 DATA 8 88 5 98 88 


Simple test DATA is given here. We are not suggesting that this is a real 
program using these DATA lines — but we do want you to provide your own 
DATA and so they are included as examples. When you type your own lines 
try to number them at intervals of ten and ensure that line 9990 is never 
overwritten or deleted, or the game will end with an ‘Out of DATA’ error. 

You also need to add the procedures in the list below to the program. The 
first procedure of each module is the only one mentioned but all the others 
within each module are also needed. 


Figure 7.40 

Start Routine Name 
Line 

11060 PROCcentre 

12000 PROCcof f 

12019 FROCcon 

134000 PROCdouble 

132500 PROCquadruple 
16400 PROCcol ourchange 
19500 FROCtune 


20000 FNgpinput 
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235000 FNread string 
320008 Error Routine 
52200 PROCdebugkeys 


There are various ways in which this program can be changed and 
‘improved’ although the only criterion that really matters is whether the 
program does what you want it to do. If it does, then be careful not to lose 
the features that you need in order to make small cosmetic changes that are 
not essential to the concept. 

To provide you with a little food for thought here are a few programming 
suggestions that you might like to try with this particular game as a basis. 


(a) The words could be chosen at random from a much larger list and 
the program ended after a certain number of tries. This would be 
particularly good if you were using it for language teaching. 

(b) The program could be made to work fairly easily in mode 1 if you 
packed it and wanted more colour. However, it might be better to 
add PROCcolour to the program rather then use the literal 
numbers used in the program as listed. 

(c) This program might be a good ‘test bed’ for experiments in the use 
of user-defined characters and graphics. Why not try to improve 
the little man and the way he walks across the screen? 

(d) Music of your own choice could be added, usirig the table in the 
user guide to help you convert the printed music into the numbers 
that you need here (p. 181 in the BBC user guide and p. 118 in 
the Electron guide). 


Don’t be afraid to try to modify the programs in this chapter. That is what 
they are for, and we are sure that in a matter of minutes you will have better 
programs for your particular purpose than we could have written. Only you 
know what the needs of your children are, so only you can specify how to 
fulfil those needs using a computer program. 
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A crucial aspect of living and its enjoyment is the ability to use the serises that 
we find at our disposal. The ability of a computer to involve a human being in 
an interactive way depends upon those senses also. This tends to mean the 
full involvement of sight and sound in the programs we like and use. 

Educational programs have a place for such considerations. We sometimes 
glibly say that a computer is a wonderful motivator for children, especially 
those who have experienced failure using traditional methods of learning and 
teaching. What we mean is that a computer can be a motivator if the 
programs being used are carefully written and involve the child totally in the 
experience of using the machine. Poor programs can have the opposite effect 
upon the child, making them as reluctant to use the computer as they may be 
to use other learning methods. There is nothing inherently motivational about 
a computer at all; in fact you could argue that a ‘QWERTY’ keyboard is a 
huge disincentive to use one. If we want to have a positive effect‘on a child, it 
is up to the software writers to take this into consideration at the time they 
plan their programs. With this in mind this chapter stresses the place that 
graphics and sound have to play in child motivation and interest. 

We have already mentioned some of the graphical and sound modules that 
you might wish to use in your programs. If you intend to exploit them to the 
full there has to be slight change of emphasis in the way you develop your 
programs. In the main part this means starting by deciding to what extent 
colour and graphic resolution determine the mode you have to use. This 
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consideration is required only because of the vast range of display modes 
available with these two machines and the differential memory requirements 
the modes have. If, as with certain other machines, the screen took a fixed 
amount of memory no matter what mode was selected, then there would be 
no problem whatsoever. This is not the case, however, and we need to give 
this question full consideration at the design stage so that we have some idea 
how much memory is going to be available for the program. 

There is a compromise to be reached in terms of colours and resolution. If 
you need excellent resolution on the screen, perhaps for a graph-drawing 
program, you will have to be happy with only two colours. If, alternatively, the 
number of colours is crucial to the program you are writing, you have to 
accept a lower resolution than you might like. Two of the programs in this 
chapter illustrate this point clearly. In ‘Answer invaders’ we wanted to have a 
well-defined spaceship and background to the game, so resolution was the 
first priority and we had to settle for only four colours. When we specified 
‘Reveal’ we wanted it to have plenty of appeal to younger children and this 
meant that we needed a large number of colours, mode 2 was the only choice 
and we had to make the best of the twenty-column screen. Be sure of your 
aims and your target audience before you make the decision about which 
mode to use. Then, once the mode has been selected, go on to the rest of the 
specification, keeping in mind what is possible in the amount of memory that 
the screen leaves for your program. 

At this point a couple of the modules should make your problems less 
rather than more. We have often considered completely redefining the 
character set when using mode 2 and mode 5 due to the chunky appearance 
of the normal characters which young children find difficult to read. 
Unfortunately this takes up a great deal of memory and is difficult to use and 
achieve. We now avoid the problem completely by using PROCdouble for 
the prompts and all information that needs to be highly legible. Whilst this 
makes the screen effectively smaller, there is still plenty of space for the type 
of prompt and information younger children need. The effect of using this 
routine is to return the characters to the same proportion as those in model 1 
and mode 4 but with less across the screen. PROCquadruple is particularly 
effective in mode 0 when using high resolution graphics. Eighty-column 
screens are difficult to read on most colour monitors, but using the 
double-width and double-height letters you have a high resolution screen 
with forty characters to the line. This is a vast improvement and makes the use 
of mode 0 in education much more viable. 

However, we would warn against the program which starts off as a good 
visual idea and then goes in search of an educational justification for its 
graphic or sound routines. It is easy to allow a ‘good’ idea to start to take over 
from the educational purpose of a program, which should always be the first 
consideration. It is far better to lose an idea than to find yourself with a 
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program with no educational value, no matter how wonderful it seems to be 
to the writer. If a compromise is needed between the various features of a 
program, we hope the decision will be biased towards the educational aims 
rather than the other features. 

Remember also that motivation is a very personal concept: what motivates 
one child or adult may have the opposite effect on someone else. We can well 
imagine what might happen if you presented a game such as ‘Answer 
invaders’ to a bright child who is more interested in answering the questions 
than watching the graphics. This is why it is so important to specify the target 
audience for your programs and not simply believe that one program can suit 
everybody. We suggest that, when you find a mismatch between program 
and user, you are prepared to do two things. Firstly be prepared to stop using 
the program until something can be done about the mismatch. Secondly, be 
prepared to try to remedy the situation yourself. You might decide to write a 
new program of your own or modify the existing one so that you eradicate the 
problem. 

The programs in this chapter have been specially written to give ideas 
about how sound and graphics can be used to motivate a child to learn. The 
first program is based on the ever-popular ‘space invaders’ concept and has 
an invader bringing the answer to mathematical problems to Earth in his 
space ship. The child has two sets of skills involved, therefore: they must be 
prepared to calculate the answer to the problem presented and then 
recognize it when it floats past, ready to shoot it down. The need for good 
graphics and animation has cut down the range of educational options the 
program involves. We could have had choice on the type of problem to be 
presented, the numerical limit, etc., if there were no graphics involved; but the 
aim here is to use the graphics to encourage the child to try the mathematics. 
We also felt that after using option routines in earlier programs you might like 
to modify this one to present problems of a different type yourself. It’s all 
yours! 

The second program is also unashamedly graphic based and is intended to 
give a flexible picture-drawing routine that you might like to use in your own 
programming. The basis of ‘Reveal’ is that you must get correct answers to 
the questions set, in order to see more of a hidden picture. As you build up 
the number of right answers you should come to understand what the picture 
is and be able to guess its subject. We have used the routine in a word game 
but there is nothing to stop you using it any way you wish. The pictures can 
be as complex or as simple as you desire and it may be that they could be 
related to the questions in some way too. For example you might devise a 
quiz on an aspect of physics, like electronics, and have hidden picture content 
which is relevant to the questions, perhaps circuit diagrammatics. This is likely 
to make the program doubly useful and have just as large a motivational 
content for the learner. 
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Score —- 6 Number of hits —- 86 
High score - 6 Number of shots - 1 
Answer invaders 


This is a graphics-based maths program which will test multiplication, with 
answers up to 99, and gives ten questions before printing out the results. 
Many of the problems in writing graphical routines are explained in the 
documentation and this should help you to overcome the same difficulties 
when you write your own programs. The mathematical routines are short and 
can be altered with a minimum of effort to test addition, subtraction or 
division, but due to graphical restraints the answer that ‘invades’ the screen 
must always be less than 100, unless you are prepared to re-define the 
characters we have provided. 


Figure 8.1 


14 MODE 1 

24 PROCcoff 

3@ VDU Ss 

40 high_score=6 
72 REPEAT 


286 
296 
508 
2104 
328 
338 
548 
58 
360 


376 
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PROCinitialise 
PROCscreen 
PROCscore_ table 
PROCupdate 
REPEAT 
PROCset sum 
PROCset alien 
MOVE alien_position, 
alien_height 
PRINT aliens; 
MOVE base_position,base_height 
PRINT baset 
finished/A=FALSE 
REPEAT 
direction=stopped 
PROCtune (1,1) 
IF INKEY-99 AND ( NOT 
bullet fired ) THEN PROCfire 
IF INKEY-98 THEN 
direction=left 
IF INKEY-67 THEN 
direction=right 
PROCmove_alien 
PROCmove_bullet 
PROCmove_base (direction) 
IF FNcolliision THEN 
PROCexplosion =: 
fini shed“~=TRUE 
PROCupdate 
UNTIL finishedZ% 
MOVE base position,base_ height 
PRINT base? 
UNTIL num_hits=1@ 
VDU 4 
VDU 28,0,31,39,27 
COLOUR white 
PRINT TAB(1,4)3"Do you want to 
try again 7 "3; 
UNTIL NOT FNyn 


380 END 
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Unlike most of the previous programs in this book the main program loop 
or loops are not called as PROCedures. All the action of the program is 
contained in the lines above and they contain all the calls to other parts of the 
program. Mode 1 allows us four colours, a good degree of resolution, and a 
pleasant typeface too. All of these features are important to this program and 
make this particular mode the ideal choice. Lines 20 to 40 initialize the screen, 
no flashing cursor and the graphic and text cursors joined, VDU 5, and set the 
high score to zero. If this was set within the master loop every new attempt 
would reset the high score, which is not the effect that we require, so this 
initialization must be outside the main loop. Line 50 marks the first of the 
three nested REPEAT/UNTIL loops and this one is ended only if the chance 
to play the game again is refused on line 370. For each attempt we set all the 
variables to initial values, draw a new graphic screen, print out the score 
headings and put the initial zero scores on the screen, lines 60 to 90 
respectively. 

The second of the REPEAT/UNTIL loops is the master game loop and is 
executed UNTIL the number of hits equals 10. Line 320 can be changed in 
several ways. You could if you wish change this to stop the game after a fixed 
amount of time, or after a fixed number of shots have been fired. Using this 
construction means that almost any criterion you choose could be the limit of 
the game; you need only to write a timing routine or the counting code and 
then include a test on line 320. If you are looking for a good educational 
criterion to stop the program, we suggest that counting the number of wrong 
answers would be worth considering. If the child is floundering with a 
program it would be better to stop the program and give some help. For this 
reason it is often a good idea to have a routine that tests the number of 
incorrect responses or the amount of time since a correct response and aborts 
the program, preferably without the child being made aware of the reason, so 
that help can be given. Another type of remedial action that a program could 
take is the changing of the difficulty level, again without the child being aware 
of the change, i.e. not “user transparent’, so that they have a greater chance of 
success. 

PROCset_sum decides the question to be asked and prints it on the screen. 
The alien then needs to be generated by PROCset_alien, printed on lines 130 
and 140, before the finished flag is reset to FALSE. The final of the nested 
loop is the code which moves each alien across the screen and accepts the 
user input. This is terminated only if the alien ship is hit by a bullet which 
causes the finished flag to be set to true. Line 200 causes a single note of the 
tune to be played, which means that the tune is played constantly whilst the 
program continues. Because this program requires movement and music to 
continue whether a key is pressed or not, we cannot use INKEY$, GET or 
GET$ to input the keys pressed, as they would halt the program execution. 
Therefore the input is detected using the negative INKEY function. Unlike the 
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others mentioned above which retum either the letter or the ASCII value of 
any key that is pressed, this function tests a single key only to see if it is 
pressed at the time that the test occurs. This is sometimes called a keyboard 
scan and can return TRUE only if the particular key tested is pressed, or 
FALSE if it is not. The difficult part is remembering the key negative numbers 
which don’t obey any logical format at all. Fortunately the complete list of 
numbers is printed in the user guides, and is one of the most thumbed 
sections in ours (BBC p. 275, Electron p. 159). These reveal that line 210 is 
testing the space bar, line 220 the ‘Z’ key and line 230 the ‘X’ key. 

The direction flag is used to move the laser base in the required direction 
and can have three possible settings: ‘stopped’ causes no movement, ‘right’ 
leads to movement towards the right, and ‘left’ the converse. If the space bar 
is pressed, PROCfire is called and the bullet is released. The other keys simply 
cause the direction flag to be set ready for the next call to PROCmove_base, 
line 260. The calls to PROCmove_alien and PROCmove_bullet are always 
executed whether a key-press was detected or not; this is how the movement 
continues regardless of any other action. Line 270 checks to see if the bullet 
has hit the alien; if a value of TRUE is returned PROCexplosion is called and 
the finished flag is set. The final action taken at each pass around this loop is 
the updating of the screen by PROCupdate. 

When execution returns, because the alien has been hit, to the outer loop 
the laser base is reset to the centre position before the next question is set. 
After ten hits, line 320, the cursors are separated by the VDU 4 on line 340. A 
text window is open across the bottom of the screen, line 340, and the player 
is offered another try. If the answer is “Y’es, execution passes back to line 50 
and the game starts again. If this offer is declined, the program ends at line 
380. 


Figure 8.2 

3976 DEF PROCinitialise 

400 RESTORE 

410 VDU 19,1,6,8,0,0,19,2,7,0,8,9, 
19,3,3,9,0,@8 

420 VDU 23,224,0,0,0,8,0,9,8,7 

430 VDU 23,225,4,4,4,156,164, 
92,124,124 

440 VDU 23,226,124,124,95,160,159, 
2,8,2 , 

450 VDU 23, 227,0,1,0,0,3,35,3,255 

460 VDU 23,228,0,0,0,0,9,9,0,9 

470 VDU 23,2279,0,8,255,8,255,9,9,0 


480 


490 
00 
410 
728 


pa Rel) 
40 
I58 


960 


378 


180 


5396 


600 


610 
620 
630 
640 
656 
660 
670 
680 


694 
70@ 


710 
720 
7306 


740 
7350 
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VDU 23,230,192,160,144,160,244, 
244,244,255 | 

VDU 23,231,2,35,3,3,3,5,;5,5 

YVDU 23,232,0,1,254,3,252,0,0,0 
YVDU 23,233,0,0,0,0,0,0,0,0 

VDU 23,234,128 ,96,144,236,242, 
200,242,236 

VDU 23,235, 144,96,128,0,0,0,0,8 
VDU 23,256,1, 1,3,3, 75 127, 128, 127 
VDU 23. 237,128,128,192,192,224, 
234,1,254 

VDU 23,238,16,56,124,1446,16, 
16,546,68 

VDU 23,255,205 ,2059,200, 200,200, 
LID, log cd 

left=TRUE =: stopped=1 :; 
right=FALSE 

finished“Z=FALSE s 

bullet _ftired=FALSE : 
display_alien=TRUE 
alien_height=975@ : 

base _height=270 : max hea ghee? 
white=2 : yellow=3 

front _aliens=FNread _string(s)° 
back aliens=FWNread_string(12) 
bases=FNread_ string (4) 
bullet#=FNread_string(3) 
bianks=FNread_ stringt12) 
explosions="*" 
alien_position=1@ : 

base position=640 

bullet height=base_height 
score=@ : correct_hit=100@ : 
bad_hit=500 

ENVELOPE1, 34717,61,9,4,0,0, 
126,0,@, 126, 126,126 
ENVELOPE2,4,90,-15,-15,10,20,20, 
126,80,0,—-126,126,126 

RESTORE 27110 

num shots=0 : num_hits=0 
ENDPROC 
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This has to be one of the longest initialization routines in the book, but it 
illustrates the number of variables and user-defined characters needed in 
even simple graphics routines and programs. As usual we hope that the use of 
long, meaningful variable names will make the program easier to follow and 
that to a certain extent they make further explanation unnecessary. Line 400 
simply resets the DATA pointer to first data lines of the program which are 
READ by lines 620 to 660. The VDU 19 commands change the default 
colours in mode 1 to be those that we need in this program. Colour 0 is left 
black, colour 1 becomes cyan, colour 2 is white and colour 3 is changed to 
yellow. The next thirteen lines each define one of the characters used later in 
the program to print the alien, base and bullet. Character 255 is defined to be 
a completely filled character grid and is used to wipe other characters off the 
screen. 

Line 580 sets the various direction pointers to the values that need to be 
passed to the movement routines. Line 590 sets up the three flags to their 
initial values; these flags only ever have two states: TRUE and FALSE. 
Various numerical constants are set on line 600. These values won’t change 
during the program’s use, but by using such constants a number of values can 
be used during program development to test their effect, then when the right 
values are found they are left in the program initialization as constants. Line 
610 sets some colour numbers; we might have used PROCcolour here but as 
only a couple of colours are needed it would have wasted space. The next 
few lines, 620 to 670, set up the picture strings by calling the required 
information from the DATA statements at the end of the program. There is 
more information about how these strings are used by this program in the 
section following PROCset_alien. More numeric variables are defined on lines 
680 to 700 before the two ENVELOPEs are defined, one of these is used to 
provide the explosion and the other the bullet effect. Line 730 RESTOREs 
the DATA pointer to the beginning of the music data and the next line zeros 
the counters. 


Figure 8.3 


7606 DEF PROCfire 
770 SOQUND@,1,157,64 
780 Bullet position=base_ positiontié 
796 bullet _height=base_height+64 
806 bullet _fired=TRUE 
810 MOVE Bullet _position,bullet_ height 
820 PRINT bullets; 
34 num_shots=num_shotsti 
840 ENDPROC 
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This procedure is called whenever the space key is pressed and there is no 
bullet already on the screen and moving. The first action is the issue of a 
SOUND using envelope 1. Notice that by using channel 0 the music is not 
affected. The length of the sound, 64 units, is so that this one sound 
command will last until the bullet has reached the top of the screen. The 
remainder of this procedure simply prints the first bullet and sets the flags so 
that another part of the program knows that there is a bullet to be moved. The 
number-of-shots counter is incremented by line 830. 


Figure 8.4 

850 DEF PROCscreen 

860 GCOL 0,2 | 

870 MOVE 10,200 : DRAW 1270,200 : 
DRAW 1276,1000 : DRAW 10,1600 
DRAW 10,200 

B88Q@ MOVE 10,450 : DRAW 450,800 : 
DRAW 725,650 

B69@ MOVE 1270,475 : DRAW 1050,74@8 : 
DRAW S50, 400 

90@ MOVE 140,226 : DRAW 1210,220 
DRAW 1110,280 : DRAW 76,280 : 
DRAW 140,220 

910 MOVE 38@,2180 : DRAW 1000,310 
DRAW 1000,400 : DRAW 580,400 
DRAW 580,310 | 

920 DRAW 500,378 : DRAW 300,460 : 
DRAW 380,400 

930 MOVE 500,446@ : DRAW 900,468 : 
DRAW 1000,400 

940 MOVE 515,360 : DRAW 515,420 : 
DRAW 360,385 =: DRAW 560,325 

950 MOVE 10,380 : DRAW 500,380 : 
MOVE 1000,380 : DRAW 1270,38@ 

960 ENDPROC 


In this procedure the screen background is drawn in white lines (GCOL 
0,2). The procedure consists entirely of MOVE and DRAW commands and 
these draw the picture as if we were drawing on a sheet of graph paper 1280 
by 1024 units. In fact using graph paper is one of the best ways to plan such 
graphics; there are specially printed pads available but ordinary paper is good 
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enough. You simply do the drawing on the paper and then work out the 
co-ordinates you need to MOVE and DRAW to and from. 


Figure 8.5 


976 
936 
9790 
1406 
1916 
10206 


1846 
1456 
1468 
1676 


DEF PROCmove_alien 

LOCAL step size 

step_size=32 

MOVE alien_position,alien_height 
PRINT alien; 

IF alien_position>11@@6 THEN 
alien_position=10 : PROCset_alien 
alien_position=alien_position 
+step size 

MOVE alien_position,alien_height 
PRINT alien; 

PROCdelay 

ENDPROC 


This procedure is a variation on the move routines in module 11. Rather 


than use parameters to pass variables, these are fixed in the code; as the alien 
always moves in one direction this too can be fixed. The step size of 32 means 
that the ship moves a whole character position at each call to the procedure. If 
this were changed to a lower figure the alien would simply slow down and a 
higher one would speed it up. The test on line 1020 is to stop the alien 
disappearing off the right-hand side of the screen and causes it to appear, with 
a new number from PROCset_alien, at the left of the screen again. The delay 
is another way of slowing the routine slightly and might be removed on the 
Electron. 


Figure 8.6 

1080 DEF PROCmove_base (direction) 
1698 LOCAL step size 

1100 step size=0 

1110 IF direction=right AND 
base_position<1@02@ THEN 
step _size-48 

IF direction=left AND 
base_position>212 THEN 
step_size=-48 


1126 


1130 
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IF direction=stopped OR 
step _size=@ THEN ENDPROC 


1146 MOVE base_position,base_height 
1156 PRINT base; 


1160 base _ position=base_ position 
+step size 

MOVE base _position,base_height 
PRINT bases; 


ENDPROC 


1172 
1180 
1198 


Like the alien movement procedure, this too is a special version of 
PROCmove_horizontal. The size of each move to be made (step_size) is set 
by the lines 1110 to 1130 and is dependent upon the value of ‘direction’. If 
the desired movement is ‘right’ then this value must be positive, ‘left’ having a 
negative step. The final test is for no movement and causes execution of this 
procedure to stop. If execution gets to line 1140, a movement is required and 
the code following moves the base in the required direction. 


Figure 8.7 


1200 
1216 
1220 
12304 
12408 
1258 
1260 


1270 


1286 
1296 
1300 
1314 


DEF PROCmove_buliet 

LOCAL step size 

step _size=64 

IF NOT bullet _fired THEN ENDPROC 
MOVE bullet _position,bullet_height 
PRINT bullets; 

IF bullet_height?>max_height THEN 
bullet _fired=FALSE : ENDPROC 
bullet _height=bullet_height 

+step_ size 

MOVE bullet_position,bullet_height 
PRINT bullets; 

PROCdel ay 

ENDPROC 


The final movement procedure is in a vertical direction and moves the 


bullet by two lines, 64 graphic units, on each occasion that it is called. Line 
1230 causes execution to end if no bullet has been fired as you would expect. 
If the bullet has reached the top of the screen, it has missed the alien and 
therefore needs no more movement. Line 1260 checks to see if this is so and 
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resets the flag variable, bullet_fired, before ceasing execution. The rest of the 
procedure moves the bullet to its new position and delays for a moment. 


Figure 8.8 

1320 DEF FNcollision 

i330 IF NOT bullet_fired THEN =FALSE 

1344 IF bullet_height< (alien_height—64) 
THEN =FALSE 

1350 IF bullet _height?alien_height THEN 
=FALSE 

1360 IF bullet _position>alien_position 
AND bullet _position< 
(alien_positionti2s8) THEN 
=TRUE ELSE =FALSE 


In this function any collision between bullet and alien is detected. There are 
many ways to do this including the use of POINT, which checks to see which 
colour is printed at a particular screen location. This is not the best method 
here because we need a large ‘window’ in which a collision might be 
detected; there would be far too many POINTs to test. We use a co-ordinate 
comparison method, therefore. This means that we can very easily set the 
sensitivity of the routine to the limits we require. The alien ship is quite big — 
four characters by two — so the test looks two lines above the ‘alien_height’ 
(line 1340), one line below the alien (line 1350) and four characters to the 
right of the alien_position (1360). If the bullet is outside these values FALSE is 
returned; if it is within this ‘window’ then TRUE is returned. By adjusting the 
number of graphic units used on these lines it would be possible to make the 
function detect more localized collisions, for example just on the number 
itself. Experiment with these values and remember this method for use in 
your own programs. 


Figure 8.9 


1370 DEF PROCdelay 
138@ LOCAL temp 
1390 temp=INKEY (3S) 
14@0 ENDPROC 


Making Life Interesting and Learning Fun 179 


If you read the notes on the last PROCdelay, the one in the ‘Times table’ 
test, you will be aware that this delay has only a fractional effect if a key is held 
down, due to the use of INKEY. It is used here because an accurate delay is 
not required. If you want to speed the program up a little, keep your finger on 
a key, not ‘Z’, ‘X’ or ‘Space bar’, and the delay will be minimized. 


Figure 8.10 


1418 
1420 
1434 
1446 
1450 
14456 
1476 
1480 
1490 


1506 
15108 
1526 
1534 
15408 
15350 


1560 
1378 
1586 
159708 
1600 


1618 


1626 
1630 


DEF PROCexplosion 
LOCAL loop 
GCOL @,3 
bullet _fired=FALSE 
display_alien=FALSE 
SOUND1 ,2,100,2@ 
FOR loop=i TO 8@ 
VDU 19,3,1,06,0,G 
MOVE alien_position+RND (128)-32, 
alien_height+RNbD (64) -—64 
PRINT explosion? 
VDU 19,3,3,0,8,0 
NEXT loop 
VDU 19,3,09,0,0,0 
FOR loop=-2 TO il 
MOVE alien_position—-32, 
alien_height+32+*1 oop—S32 
PRINT blank? 
NEXT loop 
VDU 19,3,3,0,4,@ 
alien_position=10 
IF £111%=answer? THEN 
score=scoretcorrect_hit ELSE 
score=score—-bad_hit 
IF scoreshigh_score THEN 
high_score=score 
num _hits=num_hitstl 
ENDPROC 


This routine is called if a collision has been detected and it uses a number 
of:stars (asterisks) to wipe the space ship off the screen. After the colour is set 
to red (lines 1430 and 1480) and a sound issued, this time using envelope 2, 
the first loop prints the stars. The use of a slight random element ensures that 
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each explosion is slightly different, the stars being plotted at random 
co-ordinates. The second loop uses the ‘blank’ character to wipe both the 
alien and the explosive stars off the screen ready for the next problem to be 
printed (lines 1540 to 1570). The lines from 1590 to 1630 provide all the 
code to check the answer, adjust the scores and prepare for the new problem. 
The scores to be added or subtracted are actually set in PROCinitialize, and 
you can adjust these as you require. i: 


Figure 8.11 


164@ DEF PROCset alien 

1630 £1112=STRS (RND(99)) 

1666 IF VAL (£111#)<10 THEN 
#111%4=f111%+" " 

1670 IF RND¢(4)=1 THEN £111#=answers 

1680 alient=front_alient+fills 
thack aliens? 

1698 ENDPROC 


This is one of the most interesting, if shortest, procedures in the program. 
Its purpose is to define a new string to be printed as the alien ship. To 
understand how it works you might need to refer to the DATA on lines 2050 
and 2060. The REMs suggest that the alien is defined as two parts. This is 
done to allow us to insert any number that we want (up to 99) into the string 
at the appropriate point so that it appears in the middle of the ship. This 
procedure chooses a random number and assigns its string equivalent to 
‘fill$’. This is then checked to see if it is less than 10 (line 1660) because, if it 
is, then a space must be added to the string so that its length is still two 
characters. Line 1670 sets the frequency of the correct answer’s appearance 
within the string to a theoretical one-in-four chance. Then the new alien$ is 
assigned by adding the front section to the number in the middle and finishing 
with the back section. This string will then allow the alien, and the answer that 
it contains, to be printed on screen as a single string variable. 


Figure 8.12 


1706 DEF PROCset_ sum 
1716 LOCAL part_A,part_B 
172@ REPEAT 

1738 part A=RND(8)+2 
1748 part B=RND(10) 


1756 
1760 


1776 
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1770 
1006 
1616 
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1836 


1840 
15356 
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answer=part A*part_B 
UNTIL answer<106 
answer #=STR# (answer ) 
IF answer=10 THEN 
answer t#=answer $+" " 
VDU 4 
PRINT TAB(18,2@); 
FROCdouble (STRING#S(11," ")) 
PRINT TAB(18,2@); 
PROCdouble (STR# (part A+" x 
STR (part _ BHo+" = PP") 
VDU S 
ENDPROC 
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The problem to be asked is selected and printed by this procedure. It is 
important that the answer is never more than 99 so the REPEAT/UNTIL loop 
causes new numbers to be chosen if the answer is too large. The ‘answer$’ 
has to be two characters, like the ‘fill$’, so the string is padded if its value is 
less than 10 by line 1780. In order to use the PRINT TAB construction, it is 
essential that the graphic and text cursors are separated. If this were not done, 
by line 1790’s VDU 4, we would have to do a MOVE to the correct location 
instead. Lines 1800 and 1810 wipe the old problem off the screen before the 
next two lines print the new one. The VDU 5 rejoins the cursors for printing 
graphics by other parts of the program. 


Figure 8.13 

18606 DEF PROCscore_ table 

187@ COLOUR white 

1886 VDU 4 

16906 VDU 28,8@,31,39,27 

1S64@ CLs 

191@ PRINT TAB(1) "Score — "5 
TAB(19)s "Number of hits - "’ 

1920 PRINT TAB(1)$s "High score —"; 
TAB(19)5 "Number of shots - " 

193@ VDU 26 

194@ VDU &S 

1950 ENDPROC 
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The score table is our name for all the numbers at the bottom of the screen. 
Once again, as we want to use PRINT TAB the cursors must first be separated 
by a VDU 4. Then a text window is used to make the TAB statements refer 
only to the bottom part of the screen. In this window all the headings are 
printed ready for the values to be displayed. The text window is restored to its 
default value by line 1930 and the cursors rejoined on the following line. 


Figure 8.14 


196@ DEF PROCupdate 

1976 COLOUR yellow 

1986 VDU 4 

1990 VDU 28,40,31,39,27 

2600 PRINT TAB(9,@)3score;”" "s 
TAB (36,@) snum_hits 

2010 FRINT TAB(14,2) shigh_score; 
TAB (37,23 snum_shots; 

2020 VDU 26 

24@3@ VDU S&S 

24420 ENDPROC 


In order that the scores stand out a little from the prompts they are printed 
in yellow, as set by line 1970. The window is re-defined and the numerical 
scores are printed in the correct position within the window before the 
windows and cursors are restored to their old values. Try not to confuse the 
headings printed in the earlier procedure with the values or numbers, which 
are held in numeric variables and reprinted at the end of every program loop 
by this procedure. 


Figure 8.15 

2050 DATA 18,3,1,224,227 ,230,233, 
10,8,8,8,8,225,18,3,3: 
REM front alien 

2066 DATA 16,35,1,254,180,8,8,8,8, 
226,229 ,2352,235353 
REM back alien 

2070 DATA 18,3,1,236,237: 
REM laser base 

2080 DATA 18,3,2,238: 
REM bullet 
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2098 DATA 198,0,0,255, 255,255,255, 
255,255,255,18,3,1: 
REM blank 


This group of data statements is used by FNread-string to define the 
character strings we need for the graphics. By using the ASCII code ‘18’ we 
can change the current graphics colour from within the string itself and this 
avoids the use of excessive GCOL statements and printing more than one 
string for each character. This is especially important in the alien$ where we 
need to use two colours, one for the ship and another for the number. The 
final ‘18,3,3’ in ‘front_alien$’ sets the colour to yellow before the number is 
added into the string. The REM statements should make clear which DATA 
refer to which character, but can be omitted when typing the data into the 
computer. 


Figure 8.16 

2100 REM Music Data — This Old Man 
2110 DATA149,2,137,2,149,4 

2120 DATA149,2,137,2,149,4 

2130 DATAIS?7 ,2,149,2,141,2,137,2 

2140 DATA129,2,137,2,141,4 ; 
2150 DATA149,2,121,2,121,1,121,1,121,2 
2160 DATA121,1,129,1,137,1,141,1,149,4 
2170 DATA149,2,129,2,129,2,141,2 

2186 DATA137,2,129,2,121,4 

21980 DATAS@O ,@ 


‘This Old Man’ is a repetitive tune and is therefore suitable for a program 
like this where the tune plays constantly. The DATA statements were 
prepared from the sheet music using the conversions given in the user guides, 
and there is one bar of music per line to assist in debugging. 

There are a number of standard modules required by this program too. 
The main procedures are listed below. Remember to add the whole module 
and not simply the lines mentioned in the list. 
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Figure 8.17 


12000 DEFPROCcof ft 
13008 DEF PROCdouble 
19500 DEFPROCtune 
22400 DEF FNyn 

23000 DEFFNread string 


Because we use the tune one note at a time and the music is expected to 
start at the beginning when the last note of DATA has been used, we need to 
arrange for this in our PROCtune. All that needs to be changed is a single line 
(19540) which should be altered to read as follows: 


Figure 8.18 


193540 IF pitch4=S50@ AND durationsz=@ 
THEN RESTORE 2116: G0TO195360 


‘Reveal’ game 


As explained above, this game is based on the idea that you have to 
unscramble words in order to see parts of a picture revealed. When you think 
you have seen enough to be able to guess the subject of the picture you are 
given the chance to do so and move on to the next picture. The program 
printed here will work, but the word DATA that we provide is just for testing. 
We would expect you to want to provide your own information and this is 
made as simple as possible by the manner in which the program was written; 
all you need do is change the DATA lines at the end. 


Figure 8.19 


10 MODE 2 

26 PROCinit 

20 REPEAT 

4@ PROCscreen 

7 PROCshuffle 

60 new _pict=FALSE 
76 PROCread_ name 
80 REPEAT 


76 PROCclear_words 
100 PROCread_word 


110 len=LEN (word?) 
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120 sorted#=FNsort_ word (word?,len) 
1208 COLOUR 6 
14@ PRINT TABCI2, 12); 
1=@ FPROCdouble (sorted?) 
168 COLOUR 7 
17@ ngos=@ 
1S@i new _word=FALSE 
19° REPEAT 
2 GO PRINT TABi‘Q,@); 
*Picture number — "“snpicts 
210 PRINT TAB(@,1)5 
“Number of words — "“snwords 
22 PROCinput_go 
2258 IF ans#=word? THEN 
PROCright ELSE PROCwrong 
240 UNTIL new_word 
ao nwords=nwords+t+i 
260 UNTIL new _pict OR 
nwords>max_ words 
278 npicts=npicts+ti 


aoe UNTIL nwords?>max_words OR 
npictsemax picts 

274 FROCresulits 

58@@ END 


We once again start with the master program loop which, if you study it 
carefully, will reveal a great deal about the structure of the program. After 
initialization, PROCinit, we have the master program loop which is only 
exited if you have guessed all the words or if you have run out of pictures. 
The first actions of this loop are to set up the screen format and call 
PROCshuffle. The purpose of this procedure is to ensure that the various 
parts of the picture to be revealed are in a random type order with every part 
included but no part being drawn more than once. The flag value new_pict is 
set to FALSE and the name of the first picture is READ from the data lines. 
This leads us into the next loop. 

This loop is exited by guessing the name of the current picture. The area 
where the word is to appear is cleared by line 90 and then the next word is 
READ from the data lines containing the various quiz words. Lines 110 and 
120 are required to ‘scramble’ the word; in fact the process is to sort all the 
letters of the word into alphabetical order. The next three lines print the newly 
scrambled word on the screen ready for the user to guess it. The counter that 
records the number of goes the user takes to guess the word is zeroed and the 
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new_word flag set to FALSE. The loop that starts on line 190 continues until 
the word has been guessed and simply prints updated information to the 
screen before each try is input and checked. When the word is quessed 
correctly the loop is ended and line 250 increments the counter ‘nwords’. 

Line 260 passes control-back to line 80 unless a new picture is required or 
you have guessed all the words. If you have guessed a picture then the 
counter ‘npicts’ is incremented before the outer loop checks to see if all the 
pictures or the last word have been quessed. In either of these cases the game 
has to end and so PROCresults is called. 


Figure 8.20 

5106 DEF PROCinit 

224 DIM order (16) ,char#(1@) 

22@ RESTORE 

2~4@ READ max_words,max picts 

334 lett#="abcdefghi jkIl mnopaqrstuvwxyz2" 

260 ngos=1 : nwords=1 : npicts=1 : 
max gos=2 

o7@ grxst=10 : gryst=200 : 
grid_len=/706 

2380 grwd=grid_ len/4 : 
grxend=qrxstt+4#qrud : 
gr yend=gr ystt+4#qrwd 

290 ENDPROC 


This procedure contains the values of all the constants used in the program 
and it READS a couple of pieces of information from the DATA lines at the 
end of the main program. It would have been possible to define these 
constants, max_words and max_picts, in the procedure just as the other 
variables are defined. This would have meant that if you were to change the 
words, or rather the number of words or pictures, in the DATA lines you 
would also have had to change the numbers in this procedure too. This is one 
of those little changes often forgotten, and therefore we decide to READ these 
values from DATA lines close to the words, where we hope that the likelihood 
of forgetting to change the number is slightly less. The bulk of the variables 
are used in the plotting of the grid on which the pictures will appear and are 
used by the window-setting procedures too. 
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Figure 8.21 


46@ DEF PROCread_word 
41@ LOCAL loop 

420 RESTORE 7030 

2@ FOR loop=1 TQ nwords 
44@ READ word? 

43504 NEXT loop 

460 ENDPROC 


This procedure simply reads the next word to be guessed. You might have 
assumed that this could have been done more simply. Although a repeated 
READ line would perform the task, this program contains a number of 
complications. The main one is that every time part of the picture is plotted all 
the DATA lines that make up the picture need to be used. As we have only 
one DATA pointer, the next READ statement would cause an error by 
pointing to the wrong section of DATA. To overcome this the RESTORE on 
line 420 moves the pointer to the first word and the loop READs words until 
the one required is reached. Although this makes the code a little longer it 
means that there is no possibility of an error due to the pointer being in the 
wrong place. 


Figure 8.22 


476 DEF PROCinput go 

4840 PROCmess("Type in the word 
and", "press RETURN.","") 

490 COLOUR 3 

7040 PRINT TABC(13,17)5 

91@ ans#=FNinput (len,sorted?) 

v2 COLOUR 7 

934 ngos=ngosti 

0948 ENDPROC 


A simple procedure which prints the prompt for a new guess, line 480, and 
then allows the input of as many letters as the word is long before adding one 
on to the number-of-goes counter. 
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Figure 8.23 


3040 DEF FNsort_word (word#,len) 

264 LOCAL sort?,loop 

2/@ FOR loop=i1 TO len 

380 char 4 (loop) =CHR$S (ASC (MIDS 
(word?,loop,1)) OR &20) 

798 NEXT loop 

6006 PROCselect_sort(1,len) 

6140 sort s="" 

620 FOR loop=1 TO len 

636 sor t#=sort$+t+chars (loop) 

540 NEXT loop 

650 =sorts 


This routine is called to assign all the letters in the word to an array (char$) 
ready for sorting into alphabetical order. The function falls into two parts: the 
code which puts the letters into the array, lines 570 to 590, and the lines to 
put the sorted letters back into a string, lines 620 to 650. Line 600 calls the 
sort routine itself. The use of ‘OR &20’ on line 580 ensures that all the letters 
are lower case and can therefore be sorted into correct alphabetical order. 


Figure 8.24 

660 DEF PROCscreen 

676 VDU 26 

686 CLS 

690 GCOL @,6 

706 PROCrect (grxst,gryst, 
grxend,gryend) 

710 GCOL @,7 

724 PROCcoff 

730 PROCdraw_grid 

74@ ENDPROC 


This is the first of the graphic routines in this program and its purpose is to 
set up the screen with a grid ready for the pictures to be plotted. Line 670 
restores the default windows before clearing the whole of the screen. Lines 
690 and 700 draw the large cyan rectangle that the graphics will be plotted 
on. The colour is changed to white, the cursor is turned off and then the grid 
lines are drawn by the next procedure before execution ceases. 


Making Life Interesting and Leaming Fun 189 


Figure 8.25 


750 DEF PROCdraw_grid 

766 LOCAL row,col 

770 FOR col=0@ TO 4 

780 MOVE gorxst+col*#grwd,gryst 

790 DRAW grxst+col*grwd, 
grysttgrid len 

800 NEXT col 

810 FOR row=@ TO 4 

B20 MOVE grxst,gryst+trow*grwad 

36 DRAW grxst+grid_len, 
gryst+tr owtgrwd 

640 NEXT row 

830 VDU 24,qrxstsgrysts:grxend:gryend; 

G6@ GCOL 0,64 

B7@ ENDPROC 


Although this routine might look complex at first glance it simply draws the 
white arid lines on to the cyan background. The two loops are used to draw 
the lines first vertically then horizontally. Line 850 sets the graphics window to 
the whole of the grid area and the following line sets the graphics colour to be 
cyan. 


Figure 8.26 


880 DEF PROCshuffle 
896 LOCAL loop,swop ,temp 
920 FOR loop=1 TO 14 
910 order (1lo00p)=loop 
920 NEXT loop 
28 FOR loop=16 TO 2 STEF -i 
949 SWwOp=RND (1 oop) 
9508 temp=order (swop) 
960 order (swop)=order (loop) 
970 order (loop) =temp 
98 NEXT loop 
990 nwind=1 
1W@@ ENDPROC 
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In the design of this program we decided to reveal the windows in a type of 
random order. This is done in some programs by looping around a line that 
generates a random number until it has chosen all the numbers allowed. This 
works, but is highly inefficient. What we need is a ‘shuffling’ routine which has 
all the values stored and simply shuffles them until they are in a random 
order. This is the purpose of the code in this procedure and it should be of use 
in other programs too. 

The first loop fills the array, dimensioned in PROCinit, with a number equal 
to the index, i.e. order (1) holds the value ‘1’, etc. The second loop, which 
works from the highest value down to ‘2’, chooses a location at random and 
stores the value in that location in a temporary variable (temp). Then the 
value in the element pointed to by the loop counter, and the value in the 
element chosen at random, are swopped. This continues until the loop 
counter becomes one, thus ensuring that every position has been swopped at 
least once. If this explanation isn’t clear enough for you and you want to see 
the shuffle taking place, put the following line into the procedure and then run 
the program. It will cause the array to be printed out in order after every swop 
and then wait for a key to be pressed before the next swop. 


Figure 8.27 


975 FOR count = 1 toa ié : 
PRINT "Element "“scounts;" = "5s 
order (count): NEXT count: 


By watching how the values move around you should be able to work out 
what is happening inside the array. 


Figure 8.28 

101@ DEF PROCopen wind (number ) 

1020 LOCAL x_start,x_end,y_start,y_end 

1630 x _ start=grxst+( (number—1) 
MOD 4) *qrwd 

10406 y_start=qgryst+( (number-1) 
DIV 4) *grwd 

1650 x _end=x_start+t+gqrwd 

1260 y_end=y_start+orwd 

1970 VDU 24,x_ start;y_start; 
x endsy_ends 

198@ ENDFROC 
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This whole program relies upon the windowing facility of the BBC 
computer and this is where the windows are opened ready for us to plot the 
part of the picture that we need to appear on screen. In fact we don’t plot just 
a part of the picture, we plot the whole picture, but because only a small 
window is open only the part of the picture that lies within that window 
appears. Whilst this makes the plotting a little slow it means that it is simple to 
set up the picture data. If the pictures were plotted in sixteen separate pieces 
the data required would need to be organized in a more complex manner. 

This procedure works by calculating the x and y co-ordinates of the start of 
the window required from the window number. By MODing the number we 
find out how far along the screen the required window needs to be, i.e. the x 
value (MOD gives the ‘remainder’ after division). A value of 4 will give a 
modulus of 0 and a value of 13 a modulus of 1. This indicates which column 
the window is in and can be converted into the x co-ordinate, see line 1030. 
To find the y co-ordinate we divide the window number by 4 and ignore the 
remainder, i.e. use the function DIV. This tells us which row of the grid the 
window is to start in, line 1040. The calculation of the finishing co-ordinates is 
much simpler: the width of each window is added on to the start positions 
found in the earlier calculations; this is done on lines 1050 and 1060. The 
actual window is defined by line 1070 ready for the picture to be plotted. 


Figure 8.29 

109@ DEF PROCfill grid 

1100 RESTORE 80190 

1110 IF npicts=1 THEN 1170 
1120 FOR loop=1 TO npicts-i 
11350 REPEAT 


1140 READ value 
1150 UNTIL value<—i 


1168 NEXT loop 
117@ FPROCdraw_picture 
118@ ENDFROC 


In a program such as this there are two ways to get to a particular piece of 
DATA. You can RESTORE to it, if you know exactly where it begins, or you 
can READ all the bits that you don’t want and simply ignore them. We would 
usually recommend that you use the first of the two methods but there are 
problems. In this case we have sets of picture DATA of differing lengths and 
although the lines could be numbered in the correct manner we would need a 
complex code to RESTORE to the right line. The easiest way to do this would 
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be to ‘compute’ the number of the line we need to use from the number of 
the picture we want to draw. The problem is that a renumbering program, 
including the BASIC command RENUMBER, or, more importantly in this 
case, program packers, cannot correctly alter ‘computed’ line numbers. This 
is very important and it is why we have decided to use the ‘READ and ignore’ 
way of moving the DATA pointer in this program. 

The procedure here takes this action and starts by setting the pointer to the 
first set of picture DATA by RESTORE 8010 on line 1100. If the picture we 
are plotting is number 1 then we need to use the first set of picture DATA, so 
line 1110 checks for this and stops the READ code from moving the pointer at 
all. If this is not the case, we need to ignore at least one set of DATA, so we 
can use a FOR/NEXT loop to move us to the correct DATA values looping 
around with the picture number minus 1 as the limiting value. All the sets of 
picture DATA end with a value less than —1’ so a REPEAT/UNTIL loop 
makes it simple to stop READing when the terminal value is found. We READ 
each set of DATA until we reach the end of the one before the one we want 
and then stop, leaving the DATA pointer in just the right place. 


Figure 8.30 

1190 DEF PROCwrong 

1200 ngos=ngostil 

1210 IF ngos?max_gos THEN new_word=TRUE 

1226 IF new_word THEN 
PROCmess("“Let’s leave that", 
"one for now, try", 

“the next word.") 

1230 IF NOT new_word THEN 
PROCmess ("Not quite right, 
try" ; “again. ae : as ") 

1240 PROCdelay 

125@ ENDPROC 


The action taken by this procedure depends upon the logical variable 
‘new_word’. If this is set to be TRUE, by the number of quesses for this word 
being greater than the maximum allowed — see lines 1200 and 1210 — then 
the first message is printed by line 1220. If there are more attempts to be 
allowed then the message on line 1230 is output. The slight delay is to allow 
the message to be read before it is wiped off the screen. 
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Figure 8.31 


1260 DEF PROCright 

1270 new_word=TRUE 

1280 IF ngos=1 THEN 
PROCmess("Well done, right", 
"first time.","") 

1290 IF ngos=2 THEN 
PROCmess ("Right on the second", 
iD | attempt. an 4 it my 

1306 IF nwind<=16 THEN 
PROCopen_wind (order (nwind))s 
PROCfi11 grid 

1314 nwind=nwind+tl 

1320 PROCmess("Do want to guess", 
"the name of the", "picture ? ") 

1330 IF NOT FNyn THEN ENDFPROC 

1340 PROCclear_words 

1250 PROCmess ("Type in your guess", 
"now, then press", "RETURN. ") 

1368 PRINT TAB(13,17); 

1370 anst=FNinput (LEN (pict?) , lett) 

1380 IF ans#<>pict# THEN 
PROCmess ("Not quite right,", 
"better luck next", "time. ") 

1390 IF ans#=pict# THEN 
PROCreveal picture 

14096 PROCdelay 

141@ ENDPROC 


If you guess a word correctly, several actions need to be taken. Firstly a 
congratulatory message needs to be printed and this is done on lines 1280 
and 1290. Then, if there are still parts of the picture to be revealed, another 
part needs to be plotted, line 1300. You then need to be offered a chance to 
guess the name of the picture; if you don’t want to, the procedure ends on 
line 1330. If execution passes to line 1340 then you must want to try a guess, 
so the code on lines 1340 to 1410 allow this. 

The word that you have input is cleared from the screen on line 1340 ready 
for the input of the picture name. The prompt is printed by line 1350 and 
verified input is assigned to ‘ans$’ on the next few lines. This is checked 
against the stored name, and if not the same a ‘sorry’ message is output. 
Notice that on line 1390, which checks to see if you have the answer right, 
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only an exact match is acceptable. You might try to write a routine that will 
accept slight misspellings. The whole picture is revealed if the answer is 
correct before the delay routine waits for a few moments. 


Figure 8.32 - 
1420 DEF PROCmess (messi$%,mess2%,mess3#) 
143@ VDU 28,46,31,19,27 | 
1440 CLS 

14506 PRINT TAB(1@—LEN (mess13) /2)3messl? 
1466 PRINT TAB(1@—-LEN (mess24) /2) 3; mess2t 
14706 PRINT TAB(C1@—-LEN (mess34) /2) 5 mess3t 
i486 VDU 26 

1490 ENDPROC 


This is a very simple procedure. It prints out the three parameter strings it 
was Called with, on three lines, each of which is centred on the screen. The 
VDU 28 sets a text window ready for the message area to be cleared on line 
1440. The calculations on the PRINT lines centre each of the text strings and 
the VDU 26 restores the default windows. 


Figure 8.33 


156@ DEF PROCread name 
i31i@ RESTORE 7860 

1526 FOR loop=1 TO npicts 
1330 READ pict? 

iS424 NEXT loop 

i35@ ENDPROC 


This procedure uses the same method as PROCfill_grid to READ and 
ignore a number of picture names. Only the last one that is READ from the 
DATA is the one required and it saves a computed RESTORE. 


Figure 8.34 

156@ DEF PROCclear_words 
1570 VDU 28,12,28,19,5 
1580 CLS 

i596 VDU 26 

1606 ENDPROC 
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Using the familiar technique of setting a window and then clearing it, this 
routine wipes the words, both the one in alphabetical order and the attempt 
from the screen, ready for new input in the same position. 


Figure 8.35 


1616 DEF PROCresults 

1624 IF nwords?max_words AND 
npicts<=max picts THEN 
PROCmess ("You have not quite", 
“guessed all the", "pictures. ") 

1636 IF npicts>max_ picts THEN 
PROCmess ("Congratulations,”, 
“you have guessed", 
"all the pictures. ”) 

1644 PROCdelay 

16560 PROCmess("Do you want to play", 
"again " So) 

1660 IF FNyn THEN RUN 

1670 ENDPROC 


At the end of all the words, or at the end of all the pictures, the game ends. 
This procedure prints an appropriate message and then offers another 
attempt with the same DATA. The tests on lines 1620 and 1630 decide which 
message to print. We could have used just one test in this case, but we 
decided to use two to stop the line becoming too long to be typed easily from 
this book. It would have been more efficient, but less readable, to use the 
IF/THEN/ELSE construction. | 


Figure 8.36 

1680 DEF PROCdelay 
169@ W=INKEY (300) 
1700 ENDPROC 
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Yet another delay routine. Change this to the type of routine you prefer 
from the previous programs. 


Figure 8.37 

171@ DEF PROCreveal picture 

1720 VDU 24,qQrxst3;grysts;grxend; gryend; 

173@ PROCfi11 grid 

1740 IF npicts<«max_picts THEN 
PROCmess ("Well done, let’s try”, 
“the next picture.","") 

1750 new_pict=TRUE 

1766 ENDPROC 


This routine is essential so that you can show the whole of the picture when 
the name has been guessed. The graphics window is set to the whole grid on 
line 1720 so that PROCfill_grid will show the whole picture. Then, if we 
haven’t just plotted the last picture, a message about going on to the next is 
printed by line 1740 and the logical flag ‘new_pict’ is set to TRUE. 

The bulk of the rest of the program is the DATA needed for the pictures 
and the names. This can all be changed if you wish but to test the program we 
suggest you try at least one of the pictures that we provide. You can use them 
all and the rest of the program if you wish; it is a complete game as printed. 
However, we suggest you change at least the words to some which are more 
appropriate to your purpose. 


Figure 8.38 


70006 REM Maximum number of words & pics 
701@ DATA 26,5 


It is important to change these numbers to the number of words and the 
number of pictures in your game if you change the DATA. Otherwise you 
will introduce an error (probably a “Type Mismatch’ error), or have some 
DATA which is never used. 
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Figure 8.39 

7020 REM Words to form game 

703@ DATA Mouse ,Eagle,Wheel ,Sea,Water , 
Sand,Sait,Pepper ,Food 

7046 DATA Cat,Horse,Frog,Bus,kKkite,BHird, 
House ,Ship,Apple,Pear ,Orange 


These words are the ones presented in scrambled form. Remember that 
any word in alphabetical order itself (e.g. ‘door’ ) cannot be used as it is shown 
unchanged. 


Figure 8.40 
70350 REM Names of pictures 
7060 DATA Ship, Bus,Woman,Man,House 


The picture names need to be in the right order if you are to have 
acceptable results. We suggest you use REMarks, as we have done, to 


separate and identify each set of DATA lines. 


Figure 8.41 
REM Ship Data. 


8006 
8010 
8020 
8038 
8040 
8054 
8066 
8078 
8686 
809 
81008 


8110) 


8126 
81350 
8146 
81504 
81456 
8170 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,0,4 
5,10,10,900,600 
1,0,7 

2,4,50,550 
2,5,600,5508 
2,95,550,475 
2,85,150,475 
2,85,50,550 

1,0,1 
S,200,550,500,400 
1,0,2 

5, 250,600,300,4650 
5, 400,600,450,650 
3,6,138,525,108,-1 
3,6,198,525,10,-1 
3,6,258,525,10,-1 
3,6,3108,525,18,-1 
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8186 
3190 
3200 
8210 
8226 
82306 
82460 
8256 
8266 
8270 
8280 


8290 
8306 
8316 
8326 
B33 
8346 
8350 
8360 
8378 
8380 
8290 
8400 
8410 
8420 
8430 
8440 
8450 
8460 
8470 
84380 
3496 
83500 
85108 
B526 
B8534 
8340 


85560 
8360 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
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3,6,378,525,10,-i 
3,6,430,525,10,-1 
3,6,499,525,18,-1 
3,6,550,525,10,-1 
3,6,250,575,10,-1 


3,6,430,575,10,-1 
i,@,3 
4,600,750,70,-1 
-~999 


REM Bus Data 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,0,1 

5, 100,350,600, 700 
1,9,0 
4,200,350,58,-1 
4,500,350,50,-1 
1,0,7 
4,200,350,25,-1 
4,500,350,25,-1 
1,0,4 

5S, 130,620,180,6708 
5, 200,628,2508,5670 
5, 280,620,338,678 
5, 360,620,418,678 
5, 440,620,490,6708 
5,520,620,578,678 
Ss, 130,450,190,500 
5, 700,450,250,500 
5, 280,450,330,500 
5 ,360,450,418,500 
5, 440,450,490,500 
5 ,528,430,580,510 
1,8,2 
5,130,529,570,600 
1,0,7 

~999 


REM Woman Data. 


DATA 


1,0,2 


83570 
8=80 
8390 
8549 
8416 
8620 
8634 
8640 
86350 
8660 
84/76 
8480 
8690 
8740 
8716 
8720 
8730 
8746 
873508 
87650 
8770 
8780 


8/798 
HBO 
8816 
8820 


8836. 


8840 
BEa0 
8860 
83870 
8880 
8896 
8900 


8910 


8920 
8930 
89404 
8956 
8960 
89708 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
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5,10,100,900,400 
1,0,1 

2,4,250,458 
2,5,450,450 
2,95,358,4650 
1,@,3 

5, 300,575,400,650 
1,0,5 
4,350,690,40,-1 
2,4,300,650 
?2,5,200,550 
?,85,210,540 
?,5,300,635 
2,95,300,650 
2,4,400,6508 
2,5,580,5598 
2,95,490,548 
2,5,400,635 
?,95,400,650 

5, 310,450,320, 340 
5 360,450, 380,340 
-~999 


REM Man Data. 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,8,2 
5,10,100,750,400 
1,0,2 
5,200 , 350,330,500 
5, 380,350,410,500 
5,290,580 ,470,650 
1,0,5 
4,355,690,40,-1 
1,0,2 

5, 200,710,400, 720 
5,515, 720,390, 758 
2,4,2909,650 
2,5,190,550 

27,85, 200,530 
2,5,300,4615 
?,85,290,658 
?,4,420,650 
?,5,528,550 - 
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200 


3980 
89970 
TAUO 
7010 


F020 
97030 
72046 
9056 
7860 
9076 
708 
97070 
91402 
71160 
9126 
7130 
7140 
9713508 
9168 
91708 
9186 


DATA 
DATA 
DATA 
DATA 
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?,85,505,535 
2,5,428,415 
2,85,420,650 
~999 


REM House Data 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,0,2 
5,10,100,720,400 
1,0,3 
5,100,300,600,450 
1,0,4 
5,150,530,230,610 
5,4798,530,550,4619 
5,150,390,230,478 
5, 478,390,550,478 
1,8,5 

5, 500,300,400,470 
1,@,1 

2,4,100,450 
?2,5,600,650 
?,85,350,9800 

~999 


Notice that each set of DATA must end with a value less than —1. In order 
to make this value more obvious we have used —999. 

From the standard modules provided in earlier chapters the following 
procedures and functions are needed. (This time we have provided a full list 
of the ones required, for reasons explained below. ) 


Figure 8. 


124600 
13006 
15500 
18506 
18626 
186708 
18720 
18776 
188620 


42 


DEFPROCcof f 


DEF 
DEF 
DEF 
DEF 
DEF 
DEF 
DEF 
DEF 


FROCdouble 
PROCpoly 
PROCdraw_picture 
PROCdgcol 
PROCdplot 
PROCdpoly 
PROCdcircle 
FROCdrect 
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19876 DEF PROCrect 
©4490 DEF PROCwrite_led 
220006 DEF FNyn 


This program is extremely short of memory and therefore some of the 
standard procedures have had to be shortened drastically. The new 
procedures, i.e. those required by this program, are printed in full below. As 
they are simply adaptations from existing routines we expect that you will be 
able to follow their logic from the explanation provided in earlier chapters. 
Type each of these routines as printed and adaptation should cause no 
problems. 


Figure 8.43 
200060 DEF FNinput (len,valid#) 
20010 LOCAL dels$,return$,back#, 
char4,string# 
20020 del#=CHRS(127) =: returnt=CHRF(13) 
: back#=CHR#(8) =: strings="" 
20030 PRINT STRINGS (len,"."); 
STRINGS (len, back?) ; 
20046 REFEAT 
20050 PROCwrite_led (48) 
24048 char $=GETS 
20078 IF chart=returns THEN 20130 
20080 IF char#=del# AND LEN(string$s$) >0 
THEN string#=LEFT#(string#, 
LEN (string#)—-1):PRINT back#5;"."; 
back#;:GOTO 20130 
20090 IF INSTRivalid$,char?)=0@ OR 
LEN istring?)=len THEN 
VDU 7:GOTO 20130 
201008 IF LEN (string#)=0 THEN 
char $=CHRS$ (ASC (char #4) —32) 
20110 PRINT chars; 


2012@ 8 8=stringt#=stringt+tchars 
20130 UNTIL chart#=return? AND 
strings<>"" 


20140 =strings 


202 


20000 
200108 
38020 
38030 
34046 
Rcd Fal Faber) 
»~44050 


24070 
50080 


3HOF8 
+4108 
301104 


244106 
38426 
24450 
30440 
34458 
384466 
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DEF PROCselect_ sort (top,bottom) 
LOCAL not_sorted,biggest,item 
not _ sorted=bottom 
REPEAT 
biggest=top 
FOR item=top TO not_sorted 
IF char$¢item) >char$ (biggest) 
THEN biggest=item 
NEXT item 
IF biggest< >not_sorted AND 
chars (biggest)<> 
chars (not_sorted) THEN 
PROCswop (biggest ,not_sorted) 
not _ sorted=not sorted-i 
UNTIL not_sorted=top 
ENDPROC 


DEF PROCSwop (old,new) 
LOCAL temps 
temp4=char # (new) 

char (new) =char$ (old) 
char? (old) =temps 
ENDPROC 


Testing this program 


In a program such as this, testing should be fairly simple. You just type it in 
then RUN it and watch the error messages appear. Using the sixth sense that 
you have by now developed, you then eradicate all mistakes and store the 
program for later use. Unfortunately with this program the error report you 
are likely to get all the time is ‘Bad Mode’. The program is just too long to run 
on the standard BBC as it is printed. | 

This is not a mistake because the program runs very well indeed after 
‘packing’ and as we have provided you with a ‘packer’ you can get a packed 
version quite easily. This doesn’t help you in debugging, though, because it is 
very difficult to debug a packed version of a program. Luckily the designers of 
these machines have provided an answer. All we need to do is debug the 
program in mode 5 instead of mode 2! 

The colours will look slightly strange but all the other routines will work just 
as normal and you can thoroughly test the program before you pack it. The 
line to be changed is line 10 and after debugging you should return it to its 
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original state. We suggest that you keep a number of copies of this program 
before you start to debug it. You could save yourself a great deal of time if 
you make any ‘fatal’ errors whilst debugging. All you have to do is go back to 
the last recording and start again. 


Program Testing and Refinement 


In this short chapter we need to consider how to test the programs you write 
and how you can check that they really are error free. This is not as easy or as 
simple a task as you might at first assume. There are, however, a number of 
hints and tips to help make the process simpler, if you only follow them 
through. 

The first, and major, hint that we can give you is to follow the plans that you 
developed before you sat down at the micro to write the program. If you have 
really thought out the structure for your program in a clear and simple way 
then testing it will also be a simple task. The big danger to avoid at all costs is 
adding extra ‘features’ or other ideas when you are sitting at the micro coding 
the program. This is when the problems tend to arise; because you haven’t 
planned these modifications carefully they can be the source of a large 
number of unexpected difficulties. 

We have presumed that you are going to write the programs sitting at your 
computer. This need not be the case at all. We were both trained to program 
at remote terminals using batch processing techniques, not the more familiar 
interactive situation that you are likely to use. This meant that the terminal 
was used only to get the program into the system; the writing took place away 
from the computer. It taught us to try to eliminate all possibility of failure 
before we even sat down at the computer. We would write a program and 
then leave it for a while before reading it again and trying to work out what 
would happen inside the computer as the program was executed. This had 
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two purposes: firstly, we started to understand how the computer worked 
because we tried to ‘think’ in the same way that it does; and secondly, whilst 
we didn’t expect a program to be error free on first run, we knew the program 
so intimately, from the number of times we had read it, that finding any error 
was much simpler than it would have been otherwise. In current times we 
tend to program interactively too, but the groundwork in computer 
understanding that we developed during our training becomes more rather 
than less important as we do so. 

Another hint, developed during this period, is to keep a list of variable 
names and their purpose on a pad as you code a program. This isn’t as 
important using the BBC or Electron as it might be on those with a less 
developed BASIC. If you follow the style that we have developed you will use 
meaningful variable names, in lower case text. (Remember that this need not 
take up a great deal of memory if you use the ‘packer’ program.) Real 
variable names make a program easy to follow and debug, and can make the 
use of REMarks less crucial too. If you do keep a list of all your names, often 
called a ‘program glossary’, it will help you find any variables that are 
under-used, such as loop variables, and perhaps allow you to cut down on 
the memory space taken by them. 

We also recommend you to use a routine, like the one in Chapter 6, that 
sets up the function keys for debugging purposes. This means that the line 
containing a simple error can be displayed on screen ready for editing using 
the cursor keys. It also means that by pressing a single key you can get a 
listing of your program in paged mode. Even such simple tricks as these can 
save hours in development time. 

The most important idea to keep in mind whenever you are programming 
ls that your program should cope with even the strangest inputs from a user. 
It is no use testing a routine you have developed using only the acceptable 
limits that you have set. Let’s take an input routine as an example; you might 
like to test ours using these suggestions below. If the routine is meant to 
accept only the letters ‘a’ to ‘c’ the first thing to do is see if it accepts those 
letters. If it does, you need to decide if capitals are also acceptable and if so 
change the routine accordingly. Notice that we have gone around this a 
slightly different way by allowing only lower case and then converting it if 
required. ~ 

So far so good, but there are a whole host of things to be checked yet. 
Have you tried pressing all the other keys on the keyboard, or a reasonable 
sample at least? Have you seen what happens if you press the non-alphabetic 
keys? You need to try the keys, of all types, whilst holding down the SHIFT 
key, or the CTRL key, and then both of these at the same time. We hope you 
tried the function keys whilst holding these keys down too. They can give 
some strange results. Finally, what happens if you press the cursor keys? 
There are a whole number of programs on the market that don’t check for 
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these keys and they can give some interesting screen corruptions if they are 
not disabled by using a *FX4,1 call. Only when you have checked all these 
different combinations and permutations can you be sure that the routine is 
complete — i.e. it behaves as you expect it to, no matter what the user decides 
to do to the keyboard. 

In technical terms what we have just suggested is that you develop a set of 
‘test data’ for each of the routines you are trying to develop. Whilst such a 
technique.is not essential when testing programs of this nature, as it is when 
testing serious business programming, it can be useful to think about the 
worst things that can happen at any point in a program. Then you should be 
able to find a way to ensure that your program can cope with these and 
doesn’t crash. 


Field testing 


It is very difficult to think of every possible problem. This is why trying your 
program with a few examples of your target audience is so important. Many 
problems can be found and overcome if you trial a program with such a 
group before you release it to a wider one. There are a couple of points that 
ought to be borne in mind at this trial. Firstly there is little point in testing an 
unfinished version of a program in this way. As far as you are concerned, you 
should be sure that your program is finished with no little areas that still need 
to be changed. Only if you have this confidence can the trial be of real value, 
for only then will you see those problems likely to surprise you. You need to 
keep detailed notes whilst watching the users, so that later you can go over 
these to see what changes still remain. 

Secondly you should have developed the documentation for your program 
by this stage too. Then you should offer only this information to the user and 
try hard not to start pressing the keys or giving advice every time they are 
‘going wrong’. This is difficult; you are likely to see all the ‘best’ features of the 
program, as far as you are concerned, being totally ignored. Try to remember 
that you are looking for those points in the program where any confusion is 
experienced by the users and making full notes on these. You need to keep in 
mind the fact that, after the trial and when the program is released, the users 
won't be able to ask you for help. They might be five, or even 5000, miles 
away from you, so any confusion is likely to end in frustration and mean that 
the program is under-utilized, a great pity when you have spent so much time 
developing it. 

Field testing or trialling is an important stage that a program should go 
through. Don’t skimp on the time you allow for the process. There are two 
components to be taken into account: firstly, the time that you need to spend 
watching users and making notes; secondly, the time needed to modify the 
program to eliminate the problems that the users brought to light. The second 
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part is always the most time consuming and can at times be daunting to 
contemplate. Don’t become despondent if you find rather more problems 
than you had expected; we all do. If you have taken the advice given in this 
book your program should be easy to modify, and most of the changes will be 
very simple. The more major ones just need a little more thought; try to ‘sleep 
on’ the ideas and you will often find in the cool morning light that they are far 
less complex than you had thought. 


Error reporting 


One of your major debugging and testing aids is the extensive error checking 
and reporting that BBC BASIC supports. For the most part the errors are 
reported in such a way that eradicating the problem becomes simplicity itself. 
If you make simple typing mistakes they will often be reported using the word 
‘Missing’ followed by the punctuation that is lacking or even more often with 
the ‘Mistake’ report. . 

There are, however, some error reports that don’t give you all the 
Information you need to eradicate the mistake. For this reason we intend to 
look at some of this type of report and try to suggest strategies to help you get 
to the root of the problem. All the possible error reports are listed in the user 
guides and it is often a good idea to look up the notes provided there in the 
first instance (BBC pp. 474—82, Electron Appendix B pp. 269-77). 


Error report Notes on likely cause 


Arguments This is a common report when you are developing 
procedures with a number of parameters in their 
call. It simply means that the number of parameters 
on the call line and those on the definition line don’t 
match. Go back to the line calling the procedure 
and check this carefully. 


Array If this report is given, you have probably made a 
simple typing mistake. Two kinds of mistake can be 
involved: you could have mistyped the name of an 
array or you could have mistyped a BASIC word, 
and this is followed by a bracket. This causes the 
syntax checking system within BASIC to think that 
you are trying to use an array that it isn’t aware of. 
Finally you might come across this error when 
debugging a particular procedure that accesses an 
array defined elsewhere in the program. If you have 
altered the program since that array was defined, its 
definition will have been lost and this error occurs. 


208 


Bad DIM 


No FN/No PROC 


Out of DATA 


Type Mismatch 
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To prevent this type of error always put your array 
definitions into an initialization routine ard call this 
before you call the other routines. 


The notes suggest that this occurs only with a 
negative number of elements. It also occurs if you 
try to define the same array twice Within a program. 
Check your code carefully and remove the 
unwanted DIM statement. 


These are reported if the program has found a line 
which ends a procedure or function without it being 
called by name. What has happened is that the 
program has got into this code accidentally. The 
most common cause of this type of error is the 
omission of the END statement. You should always 
include this on a line after a main program loop. We 
tend to write the line with END on first! If you 
accept our line numbering conventions, as 
explained in earlier chapters, the highest line number 
allocated to a main program loop is 999. This 
would therefore be a good line number to have as 
an END statement. 


This generally means that you have READ all the 
available DATA, and it can occur if you are wanting 
to play music continually, for example. It can also 
be caused by a RESTORE statement pointing to 
the wrong line. 


This indicates that you have tried to put a string into 
a numeric variable or vice versa. Whilst it can occur 
on INPUT or LET lines we find it a bigger problem 
when READing from DATA lines. If, for example, 
you want to read two strings and a number and 
they are in the DATA statement in the wrong order, 
perhaps number and two strings, this report will be 
given. Another way to induce this error, deliberately 
or accidentally, is to put a comma in a piece of 
string DATA that is not.enclosed in quotes, or an 
extra comma between two numbers on a DATA 
line. Note that the line number given will always be 
the line where the READ occurred and not the line 
number of the actual DATA. You will need to find 
the incorrect DATA line yourself. 
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Unfortunately some errors don’t cause an error report at all but still prevent 
the program from working. We could probably write a whole book on the 
subject, but you develop a sixth sense for this type of error if you do enough 
programming on the machine. The development of this sense is one of the 
values of typing in listings from magazines and books. The most difficult error 
that we have had to trace was in such a listing given to us by a ‘friend’. The 
program looked fine but wouldn’t work under any circumstances. We found 
the bug using the BBC’s TRACE facility, eventually! It always went wrong on 
a particular line, which became the main suspect. The answer was that a VDU 
line supposed to turn the cursor off contained a comma instead of a 
semi-colon and caused the whole display to be turned off instead. The 
TRACE facility is worth getting to know well. 

TRACE can be set to be ON or OFF. If it is ON it prints out the line number 
of every line as it is executed. This has a tendency to ruin any displays you are 
trying to develop but by keeping a careful eye on these line numbers you can 
begin to see any endless loops or notice the lines that have caused 
unexpected output. We suggest that you experiment with this facility before 
you try to use it; in practice it can be confusing at first. 

Another debugging tip to remember is that variables are retained on 
‘escaping’ from a program or by stopping its execution in another way. This 
means that using direct commands you can find the values of variables that 
might be giving problems. Say you have a variable called ‘gridx’ that is 
causing difficulties: all you need do is stop the program, use ESCAPE, when 
the problem occurs or as soon after it as possible, and then find out what 
value is currently held in ‘gridx’. This can be done by typing ‘PRINT grids’ 
directly from the keyboard. The value printed may then give you a help 
towards finding the difficulty. If a particular problem is persistent it might be 
worth inserting extra lines, numbered between tens, e.g. 23 or 5645, which 
print the values of critical variables every time they are changed. This means 
that you get rather messy displays but they can be easily removed after full 
debugging. 

One final hint is really only for those with printers. Finding bugs is often far 
easier on paper than it is on a VDU screen. This is partially because the lines 
look more, discrete and are longer than on a forty-column screen — but it really 
Is easier in our experience. If we are asked to debug a program for someone 
our first action is always to get a printout. This can then be compared with an 
original listing if one is available, or used for in-depth study. 


When you are debugging and trying to assess the efficiency of your programs 
you should always remember that they should be childproof in every way 
possible. This can involve many different considerations but there are a 
number that you should always be aware of. The first of these is the 
appearance of the screen. 
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Screen design is of vital importance when children are to use a program. It 
can mean the difference between a child being attracted to a program and 
wanting to learn what it has to offer and a child being made to feel that the 
whole area is beyond him and giving up completely. Try to break the screen 
down into a small number of areas each of which is used for a particular 
purpose. For example, you might need to have an area for prompts and 
input, another for graphics and a third for titles. If you can break a screen 
down in this manner, the user will find it easier to read the prompts, as and 
when they are needed, as they will always be in the same space on the 
screen. There is always a danger, however, that if you break the screen into 
too many parts the whole will become fragmented and less attractive 
accordingly. | 

The subject of the prompts themselves also needs thought and attention. 
When you are writing for children you need to be constantly reminding 
yourself that they don’t read quite as quickly or as well as you do. This is one 
reason why it is difficult to write programs for a wide age range. If you have 
prompts that help the older children, they will be too difficult for the younger 
ones and be a subject of boredom and possible ridicule for those older still. 
Make sure that your on-screen prompts are easy to read, by the standard of 
the children likely to be using the program. Ensure that they really are 
necessary and appear at the right point, or that they can be turned off after 
the user has become familiar with the program. Finally make them as easy as 
possible to read. This might involve shortening them, without introducing 
ambiguity, and checking that they are always printed correctly on screen. This 
is overlooked in so many cases; you find prompts which are too long for the 
window being printed on screen with words split across two lines. This can be 
overcome with thought and ingenuity, but it is even better to arrange for all 
your prompts to take less than one line in the first place. 

On some occasions, especially when writing for very young children, it is 
inappropriate to have any prompts at all. One educational software company 
we know uses only two symbols to show which keys to press. The first, a hand 
pointing at a bar, appears when you need the space bar to be pressed. The 
second, a large question mark with a face inside the top, appears when you 
have pressed the wrong key and the program doesn’t understand. You could 
plan a similar system for your programs. 

A final consideration when childproofing programs is what to do about the 
‘no go areas’ of the keyboard. By this we mean those keys that stop the 
program in some way or other. There are two keys that give particular 
trouble: the ESCAPE and the BREAK keys. There are a number of ways 
around the pressing of both these keys, and the method you use is best 
decided in relation to the kind of program you are writing. If the program is 
simple, short and doesn’t hold an amount of important data that you need to 
have, then the escape key can be programmed to re-RUN the program and 
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the child will then have to start again. The following program line will achieve 
this: 


10 ON ERROR RUN 


This can have advantages in some programs where you want a way of getting 
back to the beginning quickly, but in others it can cause chaos. Never put 
such a simple ON ERROR statement into a program until it is fully debugged. 
If you do, every little mistake and error will cause the program to be re-RUN 
and you will never find them. Alternatively you can write a slightly more 
sophisticated ON ERROR routine. As we know that the pressing of the 
ESCAPE key is given an error number of 17 we can check to see if this is the 
current error number. To do this we test the pseudo-variable ‘ERR’ and if it is 
not equal to 17 then we arrange for a full report to be given as normal. The 
following set of lines might be used to do this: 


Figure 9.1 


14 ON ERROR GOTO 32000 
320080 IF ERR = 17 THEN RUN 
320106 REPORT =: PRINT " at line “3;ERL 


There are other ways to deal with the pressing of the ESCAPE key, though. 
If you want the child to learn that this is not a good thing to do you might print 
a discouraging message before re-RUNing the program. This is simple to do if 
you are prepared to write such a procedure. The line to call such a procedure 
might look like this: 


10 ON ERROR PROCerror:RUN 


The same technique can be used to go back to a particular part of a program 
and carry on from that point. All the variables should hold their old values and 
so the program is unlikely to crash due to undefined variables. 

If you want to make the ESCAPE key totally ineffective there is a technique 
to do this too. You need to include as a very early line in your program the 
statement *FX 200,1. This makes the ESCAPE key totally ineffective and 
pressing it can do no damage to your program whatsoever. This is one of the 
most effective and therefore most recommended of the solutions so far 
suggested. There might be occasions when you would like to have a key 
other than ESCAPE cause an ‘escape type’ effect. This can be done by using 
*FX 220 followed by the ASCII code number of the key that you want to 
become the escape key. A good number to try might be 176 which means 
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that function key O (f0) is the escape but only if pressed atthe same time as 
both the CTRL and SHIFT keys. 

Unfortunately pressing the BREAK key has a very different effect on the 
variables and they are completely lost. There are techniques to save them but 
they are so complex as to be beyond the scope of this book. The most usual 
way to get around this problem is to define the break key itself to re-RUN 
your program when pressed. This is done simply by using a *KEY 10 
statement. The line to do this will probably read as follows: 


Figure 9.2 
10 *KEY 1@ OLD:iIM RUN:IM 


This means that when the BREAK key is pressed the OLD and RUN are 
effected (iM is equivalent to pressing the RETURN key) and the program 
starts again from the beginning. 

The problem with this technique is that pressing CTRL and BREAK (i.e. 
pressing both keys at the same time) clears the key definitions so the OLD 
and RUN are wiped from memory and the program stops completely. The 
only way around this particular problem is to change what happens when the 
BREAK key is pressed. This usually involves the use of machine code but we 
have discovered a way to keep BASIC programs running by typing three *FX 
commands. The first of these is always *FX 247,76 no matter which machine 
is involved. Then you need to know which type of BASIC you have in your 
machine if you are using a BBC. This is easily found; just press BREAK and 
then type ‘REPORT’. You should get a copyright message on screen which 
will say either “(c) 1981 Acom’ or ‘(c) 1982 Acorn’. This simple message 
identifies the type of BASIC in your BBC computer. ‘1981’ indicates that it is 
BASIC 1 and ‘1982’ that you have a BASIC 2 chip. There is little difference in 
normal usage but it makes a difference to the second *FX call. If you have a 
BBC with BASIC 1 this becomes *FX 248,44; otherwise (i.e. BASIC 2 BBCs 
and Electrons) it is *FX 248,20. The final call is the same for all machines 
once again and should read *FX 249,189. The idea is that the BREAK key 
starts the program again by passing execution to the BASIC startup routine 
which is contained in the BASIC chip itself. This technique is not guaranteed 
but it is worth a try if you don’t want the program to be stoppable. The only 
way to stop the program if you use both this technique and something to stop 
the ESCAPE key working (e.g.) *FX200,1) is to turn it off at the mains — 
drastic but usually childproof! 

When you have finished all your debugging and trialled your program, 
making the changes required, you need to remove all your debugging aids 
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from the program before the version can be called final. Things that need to 
be removed include function key definitions, temporary ON ERROR 
commands and debugging STOP lines. It might even be right at this stage to 
remove all unnecessary REMarks, but we would recommend that any 
program meant to be modified by the user should have these left in. Then the 
program can be regarded as finished and can be ‘packed’ if you so wish 
before being offered to those for whom it was written. Congratulations are 
probably in order if you get to this stage. We still have a number of 
incomplete projects that are never likely to get this far! 


10 


Over to You 


This final chapter includes two programs in which we try to practise what we 
have preached in the previous nine chapters. It is really time for you to start to 
develop your own programs for your own children, to help them and their 
needs. That is the real beauty and advantage of a book like this, at least from 
the authors’ point of view. 

Here we have tried to give you not only several educational criteria to 
consider when you start writing programs for your needs, but also a number 
of programming ones. This is more valuable than trying to provide you with a 
book full of listings to type into your machine. We have the opportunity to 
affect every program that you want to write from this stage forwards. Whilst 
we hope that you will try out the programs provided, we would be happier to 
feel that you will try to identify those areas in which the children in your care 
could use some help and then write a program or programs to assist them. 
This is what educational programming is all about — providing a solution to a 
problem that you currently perceive. Then the microcomputer becomes what 
it should always be: a tool in the hands of those who need it. 

Don’t feel that we are decrying the educational software that you might 
buy. It has an important part to play in teaching using computers, but it is 
intended for a general audience. The concept that needs to be 
emphasized at all stages of the educational process is the individuality of each 
person. There will always be a need for ‘custom built’ software, to cope with 
an unusual problem, or provide the details that ‘off the peg’ software could 
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never consider including. Whilst ready-made software will cover most needs 
immediately, there will be those who will want to tailor the programs to their 
situation. We hope that this book has provided you with the basic skills to 
undertake such a task with confidence. If this is the case, then we have 
succeeded in our major aim. 

To give you some ideas from which to start developing your own projects 
the two programs in this chapter represent two major program types that you 
are likely to come across again and again. For this reason we include full 
working examples so that you can understand how such a program can be 
structured, and also so that you can cut down on the amount of programming 
required by ‘borrowing’ or adapting the routines provided here. 

The first type of program is word based. There have been a number of 
these in the book already but in this case the program is meant to encourage 
the comprehension of text that has been read. The most interesting and 
valuable routines in this program are those that convert the numerous DATA 
lines into strings and then format them on screen. We can think of a number 
of ways in which such routines might be used, from the simple displaying of 
instructions to the attractive printing of children’s stories or other writing. 

The second type of program is the multi-choice test. This has become 
ubiquitous over recent years, and there are many possible applications. The 
program provided here is suitable for a whole range of ages from young 
children to those about to take a driving test. The routines to draw the road 
signs are interesting enough, but the most valuable ones as far as use in other 
programs is concerned are likely to be the routines that set’up the questions, 
print these on screen and then check the answers. These could be 
incorporated into almost any multiple-choice program with little effort and to 
good effect. 

In this chapter we have not tried to use the modules provided in previous 
chapters. Rather we have used these as a basis for the more streamlined 
procedures and functions needed in these programs. The main reason for 
doing this is to cut down the memory space taken by such long and intricate 
routines that were meant to cope with a very wide range of situations. Here 
we know the exact application of each routine and so we have tailored them 
to fit the requirements of the program. This seems the best way to use the 
modules provided earlier. They are a good way to get a program idea running 
quickly, but once the basic concept and structure are clear it is far better to cut 
out those parts of the standard module that are of little or no use to you and 
then use the memory space left to achieve your program aims. 

Over to you! 


‘Road sign’ test 


This program involves a multiple-choice routine that might be of use to you in 
other situations. It also features a much extended ‘PROCdraw_picture’ with 
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Road Sign Test. 


AM aQJh)s 


all kinds of extra facilities. This should give you a few ideas for extending its 
use in programs you want to write. 

The avowed aim is to test the learning of road sign recognition and features 
twenty different signs, all reproduced on the screen. So that it has a diagnostic 
value, there is a printout at the end of all the signs answered incorrectly. To 
give greater variation there are thirty-four possible answers, i.e. some signs 
are never displayed on screen. Another routine that might be of interest and 
use elsewhere selects the alternative answers. It is called ‘PROCread_answers’ 
and incorporates a special checking algorithm which won’t allow the same 
answer to appear twice for the same question. 


Figure 10.1 

14 MODE 3S 

24 PROCtitle page 
24 PROCinitialise 
4@ PROCset_ order 
324 PROCset_ screen 
6@ REPEAT 


120 
130 
140 
150 
166 
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PROCread answers 
PROCclear_ screen 

PROCdr aw_sign 
(sign_order (num_signs)) 
PROCset problem 

IF input=answer THEN 
PROCright ELSE PROCwrong 
num signs=num_signstl 


UNTIL num_signs?>num_questions 


MODE 4 
FROCresults 
END 
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This is the master program loop and as usual it calls all the various 
procedures in the correct order. The workings of each procedure are fully 
documented below. Line 110 checks the answer given and takes appropriate 
action, either PROCright or PROCwrong. The REPEAT/UNTIL loop is 
terminated when the number of signs tested is greater than the number of 
questions set for this test; this can be changed by altering the value on line 
190. PROCresults offers another go, so there is no need to check for this in 
the main program loop. 


Figure 10.2 

174 DEF PROCinitialise 

186 LOCAL answer 

1946 num_questions=1@8 +: num_answers=34 
s max questions=20 

2460 DIM answers (num_questions), 
Ssign_order (max questions) 

210 DIM questions# (4) ,quest_num(4) 

224 num signs=1 

220 ‘num_cight=0 =: num_wrong=0 

240 FOR answer=1 TO num_questions 

Pager) 's) answers (answer )=—-1 

260 NEXT answer 

2/0 #FX200,1 

2340 PROCcof Ff 

2°@ ENDFROC 
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Lines 190, 220 and 230 set up the various numeric constants used in the 
program. The variable ‘max_questions’ holds the number of pictures in the 
DATA statements and hence the maximum number of questions that can be 
asked without restoring the DATA pointer. The arrays are DIMensioned in 
this routine and these function as follows: 


answers(num_question) holds the wrong answers that are typed in; 

sign_order(max_questions) holds the pseudo-random order in which the 
questions will be displayed; 

question$(4) & quest_num(4) are used to hold the possible answers for each 
of the questions. 


The FOR/NEXT loop, lines 240 to 260, is used to initialize the answer array 
to hold ‘“—1’ in each element. This value is used to signal a correct answer and 
this is altered only if a particular answer is incorrect. This is used by 
PROCprint_answers to signal which ones are to be printed out at the end. 
The *FX 200,1 ensures that the ESCAPE key has no effect during the 
running of the program. The cursor is also removed on line 280. 


Figure 10.3 


5300 DEF PROCset screen 

31@ VDU 246,12 

320 PRINT TAB(2,@)5 

300 FROCdouble ("Road Sign Test.”") 
34@ MOVE 180,950 =: DRAW 1150,95@ 
300 MOVE 180,955 RAW 1150,955 
360 VDU 19,0,0,@ 
370 VDU 19,1,1,@ 
380 VDU 19,2,4,4 
5708 VDU 19,2,7,0 
440 ENDFROC 
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This is the screen initialization routine which prints the heading and then 
underlines it, lines 320 to 350. The rest of the code simply sets the colours to 
their initial values ready for the first sign. 


Figure 10.4 

410 DEF FPROCread answers 

470 LOCAL option,quest_pos,pos, found 
430 FOR option=1 TO 4 

4404 REPEAT 
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430 found=TRUE 
460 quest pos=RND (num_answers) 
470 IF quest pos= 


Sign order (num_signs) THEN 
found=FALSE 
480 FOR pos=1 TQ option 
490 IF quest _pos= 
quest numipos) THEN 
found=FALSE 


206 NEXT pos 

310 UNTIL found 

328 quest num(option)=quest_pos 
2-30 questions? (option)= 


FNread_name (quest pos) 
740 NEXT option 
328 ENDPROC 


The entire function of this procedure is the setting of the question or rather 
the four possible answers. The aim is to ensure that there is no duplication of 
the answers; i.e. each one can be part of the options only once per question. 
This is important. We know of a number of computer-based quiz programs 
that don’t include this sort of check and look silly for just that reason. The 
routine chooses four possible answers and line 470 checks to see that the 
correct answer isn’t selected, whilst lines 480 to 500 check that the answer 
hasn’t already been included in the list. The method we use is to set a flag, to 
the logical value TRUE, and then repeat the process of random number 
selection until the flag remains TRUE. This means that the answer is 
acceptable and can therefore be safely added to the list. Up to line 530 we are 
using numbers only, i.e. the number of the question; and on that line the 
string is READ and placed in the array. This saves a great deal of string 
comparison and makes the routine quicker. We use only three of these four 
answers, as the correct answer is used in place of one of these incorrect ones 
by PROCset_problem. 


Figure 10.5 

260 DEF PROCdr aw_sign (number ) 
27@ LOCAL data 

780 VDU 26 

2790 RESTORE 8000 

600 IF number=1 THEN 649 

610 FOR data=1 TO number-1l1 
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620 PROCread data 

620 NEXT data 

640 FROCdraw_picture 
6546 PROCtext colour (3,0) 
660 ENDPROC 


Due to the variations in the length ot the DATA required to draw each of 
the signs it is difficult to use a simple RESTORE statement to get to the correct 
DATA line. We could have used a computed RESTORE but due to the 
problems of renumbering such lines we decided to include a loop to READ 
past the data already used and therefore start at the information we want. 
This takes place on lines 590 to 630 and calls PROCread_data for each sign 
that needs to be skipped. All that is then required is to draw the picture and 
reset the text colour. 


Figure 10.6 


67@ DEF PROCset problem 
686 LOCAL option 
6960 answer=RND (4) 
706 quest _num(answer )= 
Ssign_order (num_signs) 
710 questions (answer )= 
FNread name (sign_order (num_signs) ) 
726 VDU 28,4,31,19,26 
738 CLS 
746 FOR option=1 TO 4 
735@ PRINT STR# (option); 
760 PROCformat 
(questions$ (option) ,17,2) 
77@ NEXT option 


780 PRINT 
790 PRINT “Enter your choice" 
80@ PRINT "( 1 to 4) — "3 


810 FROCcon 
826 input=FNinput 
8360 PROCcoff 
840 ENDPROC 
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The correct answer to the question is placed into the array on lines 690 and 
700. Line 710 places the correct string in the array and the rest of the 
procedure simply clears a text window and then prints the options on the 
screen. The answer is input ready for checking on lines 780 to 830. 


Figure 10.7 


83506 DEF PROCformat 
(string?,length,offset) 
8646 LOCAL first#,pos 
87@ IF LEN(string#)<=length THEN 
PRINT TAB(Coffset)sstring#:ENDPROC 

88@ REPEAT 
890 first$=LEF TS (string#, length) 
900 pos=length 
710 REPEAT 
F280 pos=pos-—l 
930 UNTIL pos<1 OR 

MUDS (first#,pos,1i)=" " 
946 TF pos<i THEN pos=length 
9350 first#=LEF TS (string#,pos) 
760 strings=MIDF (stringt,posti, 

LEN (string?) —-postl1) 

970 PRINT TAB(Coffset)s first? 
730 UNTIL LEN (strings) <=length 
9940 PRINT TAB(Coffset); strings 
1460 ENDPROC 


This procedure is needed to prevent long strings from being split 
awkwardly on to two lines. The parameters used are the string to be printed, 
the maximum length that you can fit on to the line and the TAB position that 
the string needs to start at. The first check, line 870, is used to see if the string 
can be printed without having to be split at all. If this is the case then the line is 
printed and the procedure ends without further ado. What is required is a 
routine that can split strings at the end of words which are, thank goodness, 
usually limited by a space. The code first cuts the string to the maximum 
length before searching, from the end of this sub-string, to find a space. This 
process continues until the whole of the string has been printed on the screen 
with no words being split. We expect that this routine will be of use in other 
programs that you need to write too. 
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Figure 10.8 


1610 
1626 
10356 
1646 
1056 
19466 
1470 


DEF FNread_name (number ) 
LOCAL value? 
RESTORE 7000 
FOR loop = @ TO number 
READ value? 
NEXT loop 
=valuet 


This is yet another dummy DATA reading procedure which simply returns 
the string appropriate to the parameter used when the function was called. 
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18690 
1100 
1118 
1120 
1136 
1140 
1158 


DEF FNinput 
LOCAL input 
#FX15,1 
REPEAT 
input=GET-48 
UNTIL input<=4 AND input>@ 
=input 7 | 


Unlike the complex input validation routines used elsewhere in this book 
this is a simple range check to ensure that a number input is within the 
acceptable upper and lower limits. The GET returns the ASCII value of the 
key pressed, so by subtracting 48 (the starting point of the numbers in ASCII, 
i.e. the code for ‘0’), we have a value representing the key that was pressed in 
the range 1 to 4. 


Figure 10.10 


1166 
1170 
1180 
1190 


1206 
12108 


DEF PROCwrong 

num wrong=num_wrong+1 

CLS 

PROCformat ("That was not the 
correct answer." ,20,0) 

PRINT 

IF num_signs<num_questions THEN 
PROCformat ("Try the next 
sign.",20,0) 
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12270 PROCdelay (30) 

1230 answers (num_sSigns)= 
quest_num input) 

124@ ENDPROC 


If the answer input is incorrect then a number of actions need to be taken. 
Firstly we increment the wrong answer counter, line 1170, and then inform 
the user of the error. If another sign is available a message is output 
encouraging a further response on line 1210. As we decided to give a full 
report of all incorrect answers the mistake needs to be stored ready for the 
report. This is done on line 1230 where the code number of the incorrect 
answer is stored. This enables us to say not only which signs caused errors but 
what those errors were. 


Figure 10.11 

1258 DEF PROCright 

1268 num_right=num_right+1 

1270 CLS 7 

1280 PROCformati"Very good, you got 
the right answer.",20,Q0) 

1290 PRINT . 

1300 IF num_signs<num_questions THEN 
PROCformat ("Try the next 
sign.",20,@) 

1310 PROCdelay (50) 

1320 ENDPROC 


If the answer was correct, there are fewer actions to be taken. The 
right-answer counter is incremented; this is not strictly necessary, since we 
could have subtracted the number wrong from the number asked to get this 
value, but it is simpler to have a separate counter. A message of 
congratulations is printed, before the same encouragement message as in the 
‘wrong’ procedure. 


Figure 10.12 

1330 DEF PROCresults 
1344 VDU 246,12 

1350 PROCcoff 

1360 PRINT TAB(4,@) 5 
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i37@ 
1380 
1390 


1440 


1410 


1420 
1430 


1440 
1456 
1440 


1476 
14386 
1496 


1506 
1516 


1520 
15368 
1546 


PRINT 
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PROCquadruple("Test Results.”") 
PRINT 

PRINT “Number of questions — "; 
num questions 

PRINT “Number answered 
correctly —- "“"snum_right 

"Number answered 
incorrectly —- "snum_wrong 

PRINT 

FRINT TAB(8,31)3"Press SHIFT to 
continue. “5 

VDU 28,0,29,39,8 

CLS 

IF num_right=num_questions THEN 
PROCcongratulations ELSE 
FROCprint_answers 

PROCshift 

VDU 26,12 

FROCdouble("Do you want to try 
another set of") 

PRINT 

PROCdouble ("questions (¢ Press 
or ‘N’ } ? - ™) 

IF FNyn THEN RUN 

VDU 26,12 

ENDPROC 


oye 


This is the final procedure of any one game. It gives a summary of the 
results and if any questions were answered wrongly it calls PROCprint_ 
answers which give a list of these, otherwise a message of congratulations is 
provided. The rest of the procedure offers another run through the program. 
Remember that each run through has a random selection of wrong answers; 
only the correct answers are stable but the questions aren’t presented in the 
same order either. 


Figure 10.13 
15586 DEF PROCprint_answers 
1566 PROCformat (namet+", here is 


a list of the ones you got wrong 
and the correct answers.",39,@) 
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157@ PRINT TAB(@,4)s "Right answer"; 
TAB (2@)5"Your answer" 

1580 VDU 28,0,29,39,15 

13590 question=1 

1400 REPEAT 

1616 CLS 

1626 displ ayed=@ 

1630 REPEAT 


1640 IF answers (question)=-1 THEN 
1700 

1650 PRINT TAB(@,displayed*3) ; 

1660 PROCformat (FNread_name 
(answers (question) ) ,20,19) 

1470 PRINT TAB(@,displayed*3) ; 

1680 PROCformat (FNread name 
(sign_order (question)) ,19,@) 

1690 displ ayed=displayed+tl 

17@6 questi on=questionti 

1710 UNTIL displayed=5 OR 


question-snum_questions 
1720 PROCshift 
1730 UNTIL questionsnum_questions 
1746 PROCshift 
17350 ENDPROC 


So that a teacher, or even the student, can see what mistakes were made 
this routine prints out a list of wrong answers. This is done in two columns, the 
first showing the correct answer and the second the answer given for that sign. 
The bulk of the code is involved with the formatting on screen of this 
information. By using PROCshift we simulate screen scrolling so that it looks 
as if the machine is in ‘paged mode’. This prevents the information whizzing 
off the top of the screen if a large number of errors was made. 


Figure 10.14 

1760 DEF PROCclear_screen 
177@ VDU 28,0,31,19,3 
178@ CLS 

179@ ENDPROC 
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Guess what this does! Wrong — it always leaves the top three lines 
untouched, which speeds up the program because we don’t have to keep 
reprinting it. 


Figure 10.15 


18@Q@ DEF PROCset_order 

181@ LOCAL temp,sign,position 

1820 FOR sign=1 TO max_questions 

1830 sign order (sign)=sign 

1849 NEXT sign 

185@ FOR sign=max_ questions TQ 2 
STEP -1 

134@ posi tion=RND (sign) 

1870 temp=sign_order (sign) 

1880 Sign_order (sign)= 

Ssign_order (position) 

1396 $ign_order (position) =temp 

1900 NEXT sign 

1910 ENDPROC 


This procedure is almost identical to the PROCshuffle in the ‘Reveal’ game. 
Its purpose is to ensure that the signs appear in a pseudo-random order in 
each game. Further details of its operation are given in Chapter 8. 


Figure 10.16 


1920 DEF PROCdelay (time) 
1936 LOCAL start 

1944 start=TIME 

1950 REPEAT 

1946 UNTIL TIME+start+time 
19708 ENDPROC 


This too is identical to earlier delay routines and simply waits for the 
specified number of centiseconds. | 
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Figure 10.17 


1980 DEF PROCshift 
1996 REFEAT 

2000 UNTIL INKEY -1 
2410 ENDPROC 


Using the table of negative INKEY values we find that the value for the 
SHIFT is —1’. This code simply loops until that key is pressed. 


Figure 10.18 

26206 DEF FROCcongratulations 

2420 PRINT 

2640 PRINT TAB(S); 

26350 PROCquadruplie("Well done 'i!t!™) 

2060 PRINT | 

2470 PRINT TAB(2@—-LEN (name) /2); 

2086 PROCdouble (name?) 

2090 PRINT 

21@6 PRINT TAB(S)s 

2116 FROCdouble ("You got them all 
right Fi") 

2120 ENDPROC 


This procedure is called only if all the answers are correct, and it replaces 
the printing out of wrong answers. 


Figure 10.19 

2130 DEF PROCtitle page 

2146 LOCAL yellow,cyan,white 
2150 yellow=1 : cyan=2 : white=3 
216@ VDU 26,12 

2170 VDU 19,0,0,0,0 
2180 VDU 19,1,3,0 
2190 VDU i19,2,4,8 
2200 VDU 19,3,7,@ 
2210 PROCcoff 
2224 COLOUR yellow 
2250 PRINT TAB(@,5); 


228 


2240 
2250 
2260 
2278 
22780 


2290 
2280 
2510 
2528 
2238 
2540 
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PROCquadruple("Road Sign") 
PRINT TAB(S,1@)5 
PROCgquadruple("Test.”") 
COLOUR white 

PRINT TAB(@,26)3;"Please type in 
your” 

FRINT TAB(Q@,22)3"name — "$s 
COLOUR cyan 

PROCcon 
namet+=FNinput_name(1i@) 
COLOUR white 

ENDPROC 


The first screen is quite simple. It prints the program title in large letters and 
then asks for the user’s name to be input. If you want to extend this section 
you can add options such as the number of questions to be asked and 
whether a printer is to be used for the results. 


Figure 10.20 

2ou9 DEF PROCsound 

2560 SOUND 1,-15,RND(255) ,2 
2o/8 ENDFROC 


In order to keep the interest of users, random sounds can be output 


whenever a slow plotting or printing procedure is taking place. We have 
included a call to this procedure in PROCdraw_picture but you might like to 
include calls in PROCdouble and PROCquadruple too. We suggest that lines 
13055 and 13555 are suitable points within these procedures for such a call. 


Figure 10.21 


6990 REM Data for answers and options. 

7000 DATA "Manually Operated Sign.”, 
"No U Turns.", "Staggered Junction 
Ahead. " 

7010 DATA “Turn Left Ahead.", 
"Qpening Bridge.","No Entry.", 
"Two Way Traffic." 


70206 


7030 


7640 


70350 


7460 


7070 


7080 


7090 


71060 


7110 
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DATA "No Stopping.", 


“low 


Flying Aircraft.", 


“No Vehicles." 


DATA 


“Roundabout”, 


"Double Bend Ahead.", 
"Uneven Road.", 


"Crossroads Ahead." 

DATA "No Right Turn.", 
“Falling Or Fallen Rocks.", 
"Miniumum Speed." 


DATA 


"T-Junction Ahead.", 


"Humpback Bridge.", 
"Maximum Speed Limit” 
REM Data for additional choices. 


DATA 


“Ahead Only.", 


DATA 


“No Pedestrians.", 
"One Way Traffic.” 
“No Overtaking." , 


“No Motor Vehicles.", 

"Stop And Give Way." 

DATA "Bend To Right.", 

“Traffic Merging From The Left.", 
"Roadworks." 

DATA “Level Crossing.” 


“Wild Horses." 


, Height "Limit." 


DATA "Traffic Lights.", ° 
"National Speed Limit." 


This is the DATA holding the names of signs. The first twenty each have a 
set of picture DATA so that they can be drawn. It would have been possible to 
include these in a separate set but by placing them here their names can be 
used as incorrect answers too. 


Figure 10.22 
REM DATA For Road Signs. 


7980 


7996 
Ba00 
8010 
8020 
BO26 
3440 


REM Stop and give way. 


DATA 
DATA 
DATA 
DATA 
DATA 


1,0,1,4,640,6708,210,-1,1,0,3 
4,640,478, 2700,-1,1,8,1 
4,640,670,190,-1,9,3,1 
7,7,18,"STOP" 

~9999 
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8450 
RO50 
8670 
BAB 
8098 
81206 
B11@ 
8120 
8120 
3140 
8150 
8160 


8170 
8180 
8190 
8200 
8210 
8226 


B23 
8246 


8250 
8266 
B27 
8280 

290 
8306 
8210 
8320 


3330 
8346 
8350 
8360 
8376 


8380 
8390 


8400 
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REM No U Turns 

DATA 1,0,1,4,640,670,210,-1,1,0,7 
DATA 4,640,470,1706,-1,1,4,@ 
DATA 4,640,720,70,-1 

DATA 3,570,578 ,595, 720 

DATA 3,685,570, 710,720,1,0,7 
DATA 4,6490,730,48,-1 

DATA 3,600,570,675,720,1,0,1 
DATA 2,4,520,810,2,5, 790,570 
DATA 2,85, 760 ,550,2,5,518, 780 
DATA 2,85,520,814 

DATA -9999 


REM Staggered Junction. 

DATA 1,0,1,3,2,640,610, 280,-1 
DATA 1,0,3,3,35,646,610,236,-1 
DATA 1,80,9,5,6190,500,675,646 

DATA 2,4,6190,560,2,5,675,660 

DATA 2,855,640, /00,5,5590,550, 

614,570 

DATA 3,675,610, 735,630 

DATA —9999 


REM Turn Left Ahead 

DATA 1,0,2,4,648,670,210,-1 

DATA 1,8,3,4,6408,670,200,-1 

DATA 1,0,2,4,640,670,190,-1 

DATA 1,0,3,5,680,560,710,750 

DATA 5,710, 750,540,720,2,4,540,775 
DATA 2,5,540,695,2,85,500,735 

DATA -9?7999 


REM Opening Bridge 

DATA 1,4,1,5,2,640,610,280, 
-1,1,0,7 

DATA 3,3,6486,6146,250,-1,1,0,8 
DATA 2,4,465,505,2,5,505,570 
DATA 2,85,505,505 ,5,505,5085, 
204,570 

DATA 2,4,815,505,2,5, 780,570 
DATA 2,85, 780 ,505,5, 740,505, 
780,570 

DATA 2,4,5945, 580 ,2,5,698,690 


8410 
8426 
5436 
3446 
8450 
8468 


8478 
8480 
83490 
8500 
851 
8520 


85.20 
8544 
B38 


83466 
6378 
B38 
3590 
84606 
8614 


3420 
3430 
8646 
8650 
8666 
84676 
84686 
8490 
8706 


8716 
3726 
8730 


8748 
87230 
87640 
8776 
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DATA 2,85,540,599,2,5,688, 700 


DATA 2,85,690,699,2,20,550,515 
DATA 2,21,740,515,2, 20,550,525 
DATA 2,21,740,525,2, 20,550,540 


DATA 2,21,740,5408 
DATA -—9999 


REM No entry 

DATA 1,0,1,4,640,670,210,-1 
DATA 1,0,3,4,640,6/706,200,-1 
DATA 1,0,1,4,640,670,1970,-1 
DATA 1,46,3,5,480,620,795,716 
DATA —-9999 


REM Two Way Traffic 

DATA 1,0,1,3,3,640,616,280,-i1 
DATA 1,0,7,3,3,640,610,230, 
-1,1,0,0 

DATA 3,995,908 ,610,4650 

DATA 3,665,559 ,4630, 650 

DATA 2,4,580,650,2,5,625,656 
DATA 2,885,605 ,675,2,4,655,550 


DATA 2,5,700,550,2,95,675,525. 


DATA —-9999 


REM CLearway 


DATA 1,8,1,4,640,678,218,-1,1,8,2 


DATA 4,640,470,17@,-1,1,@,1 
DATA 2,4,780,790,2,5,5008,520 
DATA 2,85,4990,570,2,5,750,8108 
DATA 2,85,780,790,2,4,520,810 
DATA 2,5,790,570,2,85, 760,530 
DATA 2,5,510,760,2,85,520,910 
DATA -9999 


REM Low flying aircraft 

DATA 1,0,1,35,3,6480,610,280,-1 
DATA 1,0,3,3,3,640,610,2350, 
-1,1,0,6 

DATA 2,4,575,645,2,9, 750,555 
DATA 2,85, 740 ,540,2,5,560,635 


DATA 2,85,570,640,2,4,660,595 


DATA 2,5,71@,655,2,95, 705,660 


231 


232 


8780 
3790 
8800 
8810 
8820 
83830 


3840 
3830 
8860 
8876 


8aee 
889O 
8900 
8910 
8920 
3930 
8940 
B930 
39766 
8976 
39380 


8998 
97600 
9016 


9020 
9630 
7240 
76364 
7260 
7076 


9080 
70968 
7100 


9110 
97126 
9130 
9146 
7150 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
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2,5,630,605,2,95, 660,595 
?,5,638,515,2,95,625,520 
?,5,630,605,2,85, 660,595 
2,4,732,515,2,5,760,575 
2,85,730,545 

~9999 


REM No vehicles 


DATA 
DATA 
DATA 


1,0,1,4,640,670,210,-1,1,8,7 
4,640,670,170,-1,1,0,08 
-~9999 


REM Double Bend. 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,8,1,35,35,640,619,288,-1 
1,0,3,3,3,640,610,230,-1 
1,8,8,5,700,510,715,6508 
3,8,700,650,16,-1 

5 ,590,550,685,6708 
3,8,605,550,16,-1 
?,4,630,550,2,5,710,650 

2,85, 680,650,2,5,600,550 
2,95,630,550,3,3,593,670,8,-1 
~9999 


REM Roundabout Ahead 


DATA 
DATA 


-1,1, 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,0,1,3,3,640,610,290,-1 
1,0,7,3,35,640,610, 239, 
0,0 
4,640,610,90,-1,1,0,7 
4,640,610,60,-1 
2,4,640,610,2,5,648,720 
?,4,648,610,2,5,540,5408 
2,4,640,610,2,5,740,540 
~9999 


REM Uneven Ground 


DATA 
DATA 


-i1,1, 


DATA 
DATA 
DATA 
DATA 
DATA 


1,0,1,3,35,640,619,280,-1 
1,0,7,3,3,640,618, 230, 
9,0 

4,590,560,45,-1 
4,698,560,45,-1 

5 ,510,530,770,580,1,0,7 
5 ,510,500,770,530 

-9999 


7160 
71706 
9186 


97190 
97200 
9218 
9228 


9230 
9240 
9250 
9268 
9270 
7288 
9298 
9300 
9318 
9320 
9330 


9346 
9256 
9266 


9378 
9384 
9290 
7400 


9410 
9420 


9430 
9446 
745 
94546 


94708 
7486 


9490 
9500 
9510 


REM 
DATA 
DATA 


-1,1, 


DATA 
DATA 
DATA 
DATA 
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Cross Roads 


1,0,1,3,3,640,610,280,-1 
1,0,3,3,5,640,6108, 230, 

0,2 

5 610,500,675, 660,2,4,610, 668 
? 5,675, 660,2,95,648,700 

5 ,550,600,730,628 

~9999 


REM No right turn. 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,0,1,4,640,670,210,-1 
1,0,7,4,640,670,170,-1,1,8,08 
5 565,578,599, 7508 

5,590, 720,750,758 
?,4,750,750,2,5,765,735 
?,85,750,720,1,8,1 
?,4,780,798,2,5,500,520 
2,85,499,578,2,5,750,810 
?,985,780,790 

~9999 


REM Falling Rocks 


DATA 
DATA 


-1,1, 


DATA 
DATA 
DATA 
DATA 
3,-1 
DATA 
DATA 


1,0,1,35,3,640,610,290,-1. 
1,0,7,3,3,640,618, 230, 

0,0 

2,4,465,505,2,5,580,490 
2,85,620,505,2,4,635,505 
?2,85,615,565,4,780,530,20,-1 
4,650,620,15,-1,4, 700,580, 


4,650,580,8,-1,4,658,540,3,-1 
-9999 


REM Minimum 3S@MPH 


DATA 
DATA 
DATA 
DATA 
DATA 


1,8,2,4,649,670,218,-1,1,8,3 
4,640,670,200,-1,1,08,2 © 
4,640,47@,190,-1,9,3,2 
8,9,10,"30" 

~9999 


REM T-—Junction 


DATA 
DATA 


-1,i, 


1,0,1,3,3,640,610,27980,-1 
1,0,3,3,3,648,6108,230, 
a,e 


233 


234 


93520 
93:30 
99408 
95536 
9360 


9370 
973586 


93590 
7606 
7616 
96208 
9630 
9540 
9650 


97660 
7670 
9680 
9696 
7700 


DATA 
DATA 
DATA 
DATA 
DATA 
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5, 610,500,675, 660 
5 570,640,475, 640 
5 ,675,610,710,668 
3,4,710,635,25,-1 
-9999 


REM Hump Back Bridge 


DATA 


-1i,1, 


DATA 
DATA 
DATA 
DATA 
DATA 
DATA 
DATA 


1,0,1,3,3,640,618,299, 
a,7 
3,3,640,610,240,-1,1,8,0 
5 ,510,530,770,580 
4,640,560,70,-1 
S,518,5230,770,5980 
1,0,7,5,510,499, 770,538 
4,640,540,40,-1 

-9999 


REM 30 M.P.H. Maximum. 


DATA 
DATA 
DATA 
DATA 


1,0,1,4,640,670,210,-1,1,0,3 


4,640,670,170,-1,9,8,3 
8,8,10,"30" 
~9999 


Each of these sets of DATA contains the information required to draw just 
one sign. This is used by PROCdraw_picture and the —9999 is used as a 
terminating value. We suggest you test this program particularly rigorously, to 
ensure that this picture data is correct. 

The following routines need to be added from the standard modules in 
Chapters 5 and 6. 
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12000 DEFPROCcof f 

12010 DEFPROCcon 

130600 DEF FROCdouble 
135506 DEF PROCquadruple 
123506 DEF FROCpoly 
224040 DEF FNyn 
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Due to the extra graphics and inputs required by this program some of the 
modules have been modified. To make it easier for you to type in we are 
printing in full all the modules that have been changed. Some have needed 
line number changes so don’t try simply to include the standard versions. If 
you are fully familiar with the BBC editing system then you might be able to 


save yourself a little time. 


Figure 10.24 


176108 


17626 LOCAL value 

17026 REPEAT 

17048 READ value 

17@45 FROCsound 

170356 IF valuec@ THEN 17160 

170450 ON value GOTO 17076, 170860, 
17090, 171@@, 1711@, 17120, 
17130, 1714@, 17150 

17072 PROCdgcoi:GOTO 17160 

170380 PROCdplot:GOTO 17168 

1709R FROCdpoly:GOTO 17160 

171@0 PROCdcircie:GOTO 17160 

17110 FROCdrectangle:GOTO 17160 

17126 FROCtnormal: GOTO 17160 

17136 FROCtdouble: GOTO 17160 

17148 FROCtquad: GOTO 17160 

171350 PROCtcol our 

17148 UNTIL value<@ 

17176 ENDFPROC 

17180 REM 

171706 DEF FROCdgcol 


17200 
17210 
17220 
17230 
17246 


17250 
17260 
17270 
17236 


DEF PROCdraw_ picture 


LOCAL type,number 
READ type ,number 
GCOL type,number 
ENDPROC 

REF 


DEF FROCdplot 

LOCAL number ,x pos,y_pos 
READ number ,x pos,y_pos 
PLOT number ,x pos,y_pos 
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17290 
173080 


17310 
17326 


173308 


17340 


17350 
17366 


17376 
1723380 
17390 
17406 


17416 
17420 


174350 
17440 
17450 
17460 


17470 
17480 


17496 
173500 
17510 
17520 
1735350 
17548 


175356 
17560 
17570 
17386 
17596 
17600 
17610 
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ENDPROC 
REM 


DEF PROCdpoly 

LOCAL sides,x pos,y_pos, 
radius,fill 

READ sides,x pos,y_pos,radius, 
fill 

PROCpoly (sides,x_ pos,y_pos, 
radius,fill) 

ENDPROC 

REM 


DEF PROCdcircle 

LOCAL x_pos,y_pos,radius,fill 
READ x_pos,y_pos,radius,fill 
FROCpoly(15,x_pos,y_pos, 
radius,fill) 

ENDPROC 

REM 


DEF PROCdrectangle 

LOCAL low_x,low_y,high_x,high_y 
READ low_x,low_y,high_x,high_y 
PROCrectangle(low_x,low_y,high_x, 
high_y) 

ENDPROC 

REM 


DEF PROCtnormal 

LOCAL xpos,ypos,text# 

READ xpos,ypos,texts 

PRINT TAB(xpos, ypos) ;text$; 
ENDFPROC 

REM 


DEF PROCtdouble 

LOCAL xpos,ypos,text# 
READ xpos,ypos,text? 
PRINT TAB(xpos,ypos) ; 
PROCdouble (text) 
ENDPROC 

REM 


17620 
17630 
17646 
17650 
17660 
17470 
17680 


17690 
177806 
17718 
17720 
17730 
17740 


17/7350 


17760 
1777@ 
17780 
17790 
17800 
17810 
17820 


17830 


17840 
178350 
17860 
17870 


17880 
17890 
17980 
17916 
17920 


17930 


17940 
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DEF PROCtquad 

LOCAL xpos,ypos,texts 
READ xpos, ypos,text# 

FRINT TAB(xpos,ypos); 
PROCquadruple (text) 

ENDPROC 

REM 


DEF PROCtcol our 

LOCAL fore,back 

READ fore,back 
PROCtext colour (fore,back) 
ENDPROC 

REM 


DEF PROCrectangle(low_x,low_y, 
high_x,high_y) 

MOVE low_x,low_y 

DRAW high_x,low_y 

PLOT 85,high_x,high_y 

DRAW low_x,high_y 

PLOT 85,low_x,low_y 

ENDPROC 

REM 


DEF PROCtext colour (foreground, 
background) 

COLOUR foreground 

COLOUR background+128 

ENDPROC 

REM 


DEF PROCread_data 
LOCAL value,dummy ,dummy? 
REPEAT 
READ value 
IF value=1 OR value=9 THEN 
READ dummy , dummy 
IF value=2 THEN 
READ dummy ,dummy , dummy 
IF value=3 THEN READ 
dummy , dummy , dummy , dummy , dummy 
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238 
179356 


17946 


17976 
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IF value=4 OR vaiue=S THEN READ 
dummy ,dummy , dummy , dummy 

IF value=6 OR value=7 OR 
value=8 THEN READ 
dummy , dummy , dummy? 

UNTIL value<-li 


17980 ENDPROC 


PROCdraw_picture has been extended by the addition of five new 
procedures. The first three additions, PROCtnormal, PROCtdouble and 
PROCtquad, allow the printing of text in three sizes within a picture. 
PROCtcolour allows you to define new foreground and background colours. 
PROCread_data is called when we are skipping some DATA lines and just 
READS the correct number of values into a dummy variable. Once again the 
—9999 is used as a terminator as it is less than —1. 


Figure 10.25 


28000 
20060 


2006708 


20086 


26100 
20110 
201206 
2@135 
20140 
20150 


20140 


DEF FNinput_name (lend) 
LOCAL delete?,returns,back_ space, 
char’, firstZ%,string? 
del etet=CHRS (127) s:returnt=CHRSF (13> 
sBack_ spacet=CHR (8) sstringt="" 
PRINT STRINGS (lenz,".7) 3 
STRING? (lenZz,back_space#); 
REPEAT 

#FX2O02,48 

char #=GETS 

PROCsound 

IF char$=return? THEN 20210 

IF char$=delete? AND 

LEN (string?) >@ THEN 

string#=LEFT# (strings, 

LEN (string#)—1):PRINT 

back space#;"."sback_ space$s;: 

GOTO 20210 

IF ((char$<"“a" OR char$>"z") 

AND charés<>" ") OR 

LEN (string#)=lenz THEN 

VDU 7:GOTO 262716 
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241172 IF LEN(string#)=@ OR 
RIGHTS (strings,1)=" " THEN 
first“Z=TRUE ELSE firstZ%=FALSE 
=~2186 IF firstx THEN 
char $=CHRS (ASC (char?) —-32) 
24199 PRINT chars; 
2A2aB string#=string#+char# 
~8218 UNTIL char%=returns 
ea234 =stringt 


As the only string that is needed from the user is their name this is a 
cut-down version of the general-purpose modules that always converts the 
first character to upper case and the rest to lower case. In all other ways it is 
similar to the original version. 

After typing in the whole of the program it is essential to do a thorough 
debugging and take particular notice of the pictures on the screen. Even 
simple mistakes in the picture data can cause major problems. Keep a note of 
the problems that occur as you watch the routines and then find the 
appropriate section to check. 

This is a difficult program to input, but the result is well worth it, and it 
should inspire you to try your hand at writing such programs. 


‘Cloze procedure’ 


One of the best ways of encouraging children to read for meaning, i.e. their 
comprehension of what they read, is to delete a number of words from a 
passage and then to see if they can provide suitable replacement words for 
the gaps. This is called ‘Cloze procedure’ and it is becoming a recognized way 
of testing and teaching reading skills. The usual method of creating pieces of 
test for this procedure is to delete every fifth or seventh word, ignoring all 
proper nouns, i.e. those starting with capital letters. This seems a simple task 
for a computer to perform but there are problems, as we will discover as we 
go through.this program. 

The core of the program might be used simply to input and then output the 
modified text to a printer but we decided to go one step further and have the 
computer give the test too! As there are four colours available in mode 1 we 
have used colour changes to show where our input is to go. This is another 
idea that might be useful in other programs you are planning to write. The 
final feature of the program is the screen formatting routine which ensures 
that the screen text is always neat and up to date. 
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Figure 10.26 


1@ MODE 1 

2@ PROCinitialise 

28 PROCset_ blocks 
40 PROCformat_screen 
34 PROCprint_screen 
64 REPEAT 

78 PROCinput_move 
80 UNTIL finished 
90 VDU 26,12 

i@@ END 


The master program is very simple. From initialization we need to decide 
where the gaps are to occur in the text. PROCset_blocks does this and splits 
the text at each of the gaps. PROCformat_screen is used to set up the arrays 
that will be printed by PROCprint_screen. Then we need both to input the 
user’s words and reformat the screen after input; this action is taken by 
PROCinput_move. The logical value of ‘finished’ is used to flag the end of the 
program, at which point the screen is cleared. 


Figure 10.27 


118 DEF PROCinitialise . 

120 DIM block#(25) ,word_valuet (25), 
word position(25,1) ,screens#(13) 

136 VDU 23,140,80,32,96,255,976,32,0,0 

140 VDU 23,141,0,4,6,255,6,4,8,0 

15@ *FX4,1i 

1460 *#FX225,128 

178 left$=CHRt &88 : right#=CHR? &89 

186 £@%=CHRS(%8@) =: £2S=CHRS (282) 

19@ PROCcof Ff 

208 punctuation$=",.535°7"eunn” 3: 
left_arrows=CHR#(14@) : 
right_arrows=CHRS (141) 

21@ finished=FALSE =: spaces=" " ; 
ends="K##EKE" 

220 yell ow#=CHRS (17) +CHRS (2) =: 
red#t=CHRS (17) +CHR (1) 

230 white#=CHRS(17)+CHRS(3) : 
padding#=STRINGS (30, space?) 
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249 current=1 : word _gap=s | 

200 PRINT TAB(@, 23) sSTRING#(46,"_") 

266 PRINT TAB(6, 28) sred#3"f@"swhitests 
" - Print out text as shown." 

276 PRINT TAB(190,29) sredt3 "f2"35 
white#;" -— Leave the test.” 

280 PRINT TAB(@,3@) 5 yellows; "a"s 
white$;" to "“syellow$;"z"swhite$; 
" —- Enter a word in the gap shown." 

290 FRINT TAB(4,31)3 yellows; 
left_arrows;" "“right_arrows; 
whitets;" — Move to previous / 
next gap."s 

382 FOR looap=1i1 TO 25 

3219 biock? (loop) =paddings 

228 word values (loop)=" 

EA.) NEXT loop 

340 FOR loop=1 TO 13 

Seer Fi) screens (loop) =padding$s 

368 screen4(loop)="" 

376 NEXT loop 

3586 ENDPROC 


After DiIMensioning all the required arrays on line 120, we define two 
characters which are used as left and right arrows, lines 130 and 140. The 
lines from 150 to 180 are all concerned with the setting up of the function 
keys and the cursor keys to return the values that we require in the program. 
The *FX 4,1 sets the cursor keys to return numerical values of 136 to 139 and 
the *FX 225,128 sets the user-defined function keys to return values of 128 
to 137. Then we set these values into strings for later testing. 

Other constants used in the program are set to their initial values on lines 
200 to 240. In order to be able to change colour using a string we use an 
alternative form of the normal GCOL statement. PRINTing the ASCII value 
‘17’ followed by a colour number has an identical effect. This is what the 
‘yellow$’ and ‘red$’ on line 220 are set to do. If you wish to set the gap 
between deleted words to any other value the constant on line 240 should be 
changed. Remember that the higher this number the easier the text is to 
complete and vice versa. We wouldn’t suggest values less than or equal to 3, 
however. The screen prompts are printed only once so they are written into 
this procedure at lines 250 to 290. Lines 300 to 330 initialize the arrays to 
dummy values as a way of overcoming a problem in the way that the BBC 
and Electron handle string variables. 
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If you are not interested in this discussion of internal variable handling then 
skip this paragraph completely. Some computers that use BASIC have the 
ability to dimension strings in just the same way that arrays are dimensioned. 
This means that the machine will allow that amount of space in its memory for 
the string and no more or less. Using BBC BASIC we can use string variables 
without any kind of declaration of their length whatsoever. There is a penalty 
to be paid for this feature, however, as every time the space left for the 
variable is filled the BBC allocates a new space for it where it will fit easily. 
This means that the variable is held in two spaces and unfortunately the first 
space is not used again. We hope that you can see the problem; if a variable 
starts small and gets bigger it might occur in variable memory space several 
times and therefore a great deal of memory is wasted. In order to overcome 
this handicap it is essential to force the BBC BASIC interpreter to set aside 
enough space for the longest string that is ever going to be held in a particular 
variable. This is the function of lines 300 to 370 where the arrays are ‘padded’ 
using a string called ‘padding$’. 


Figure 10.28 


298 DEF PROCset_ blocks 

40@ block _number=1 : word_start=0 

41@ word_end=0 : word_count=1 

4206 current_line#t="" : spaces=" " 

43@ end_of_text=FALSE 

446 REPEAT 

450 READ next_lines 

466 IF next_linet-end? THEN 
end _ of text=TRUE ELSE 
current_line#t=current_lines 
+next_lines 

47 end_of line=FALSE 

48¢ word start=word start-l 

496 REPEAT 


248 word end=word start 

21 REPEAT 

320 word start=word endtil 

aU) word end=INSTR(current_lines 
,spaces,word start) 

240 IF word_end<>@ THEN 
word count=word_count+tl 

var oar] UNTIL word _count>word gap 


OR word _end=0 
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ao IF word_end=6 THEN 
end of line=TRUE : GOTO 4640 
37@ IF INSTR (punctuations, 


MID#(current_line#, 
word end-1,1))<>@ THEN 
word end=word_end-1 


380 wor d#=MID¢$ (current_lines, 
word start,word_end-word start) 
278 IF FNnot_valid(word?) THEN 


word count=word count-l1s 
word start=word_end:GOTO 650 


640600 block? (block_number )=LEFTS 
C(current_line#,word_start-—1) 
610 current_lines=RIGHTS 


(current_line?,LEN 
(current_line?)-word_end+tl1) 


623 block number=block_numbert+l 

630 word count=0 : word_end=6 : 
word start=@ 

640 UNTIL end_of_ line OR 


block _ number >=25 
654 UNTIL end of text OR 
block number >=25 
660 IF end_of text THEN 
block# (block number)= 
. current_linet 
67@ last Bblock=block_number 
680 ENDFROC 


Despite its length and rather strange coding this procedure has a simple 
basis. Its purpose is to split the text into blocks each begun by a deleted word 
and ended by the next one. This is complicated by the use of DATA lines to 
hold the text as they can be of variable length and also by the requirement 
that we don’t want to delete proper nouns. 

The bulk of the action takes place inside three nested REPEAT/UNTIL 
loops. The outer loop READs the DATA lines, i.e. the text, and checks that 
we have not come to the end. The innermost loop counts through the 
number of words required between deletions and is only exited when this 
number of words has been found or the line is ended. The middle loop is 
where the splitting of the test occurs. Line 570 is used to check if the last 
character in the current word, i.e. the one to be deleted, was a punctuation 
mark. If it is, it needs to be left in the text, so the word-end counter is 
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decremented by one. Line 580 removes the word from the text ready for 
checking to see if it is a proper noun. If it is a proper noun, it is returned, 
effectively, to the string by line 590. The next line takes the block of text 
before the word that has been removed and assigns it to one element of the 
array. We then need to process the words that followed the gap and this is set 
on line 610. The remainder of the loop resets the variables for the remaining 
text to be rescanned. - 

At the end of the procedure all the DATA has been read from the lines, all 
the gaps have been found and all the text made ready for printing on screen. 


Figure 10.29 


690 DEF PROCprint_ screen 
7@0@ LOCAL pos,vpos,position 
710 VDU 28,0,22,39,0 
726 FOR Lline=1i TO 12 
738 FRINT TAB(C@, (line-1) #2); 
screens (line) ;SPC(39- 
LEN (screent(line))); 
746 NEXT line 
726 FOR position=1 TO last_biock-I! 
760 FROCset location 
(position, yeliow#?) 
7/78 NEXT position 
7860 PROCset location(current ,red?#) 
790 VDU 28,040,351 ,397,24 
BOO ENDPROC 


31@ DEF PROCformat_screen 

320 FOR line=i TO 12 

B28 screen? (line)="" 

840 NEXT line 

850 line=1:block=l:send_of text=FALSE 

860 buffert=block? (block) 

870 REPEAT 

cea IF LEN (buffer?) + 
LEN (word value (block) )<=4@ 
THEN FROCadd_ word 

B90 IF LEN (buffer$)+LEN 
(word valuet (block) ) >4@ 
THEN PROCremove_line 
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760 UNTIL block=last_block OR 
linesi2 

710 PROCremove_line 

920 ENDFPROC 


The aim of this routine, comprising two procedures, PROCprint_screen 
and PROCformat_screen, is to print the text on screen in an attractive and 
easy-to-read manner. It would have been simple just to clear the screen and 
then reprint the text each time an amendment has taken place, but this leads 
to a great deal of flicker; we decided to avoid it by overwriting each line with 
the updated line filled or padded with spaces to ensure that all old text is 
removed, lines 720 to 740. The loop from line 750 to line 770 simply prints 
the yellow gaps, and the current one of these is then reset to red on line 780. 
Both of the VDU lines set text windows to avoid overspill to other parts of the 
screen. 

The formatting of the screen is achieved by PROCformat_screen and 
involves the use of a separate array from that holding the blocks of text. All 
the strings in the array screen§$ are firstly set to null values, lines 820 to 840. 
The rest of the routine simply adds words to a buffer string until adding a new 
word would make the string longer than the space available on one line of the 
screen. That line is then removed from the buffer by PROCremove_line and 
the rest of the text is examined in a similar manner. The procedure ends when 
we are at the last block of text or when there are twelve lines already 
formatted. It is important to remember this restriction on the length of the text 
when you set up the DATA statements. 


Figure 10.30 
9306 DEF PROCadd_word 
946 IF block=last_block THEN ENDPROC 
9350 word _position(block,@) 

=LEN (buffer?) 
966 word_position (block,1)=(line—-1)*2 
970 buffert#=buffertt+word values (block) 
986 block=block+ti 
$90 buffert=buffert+blocks (block) 
1@0@ ENDPROC 


1@1@ DEF FROCremove_line 
1620 line_end=FNlast_space (buffer?,41) 
1030 screen (line) =LEFTS (buffert,line_end) 
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10@4@ buffers=RIGHTS (buffers, 
LEN (buf fer?)—-line_end) 

1050 line=lineti 

1466 ENDFROC 


These two procedures are used by the two above to add or remove the 
words from the buffer. Line 940 is a safequard to ensure that we aren’t at the 
end of the text. Lines 950 and 960 record respectively the x and y 
co-ordinates of any of the gaps, which might have been replaced by words 
from the user at this point, so that they can be highlighted in colour at a later 
stage. The other lines in PROCadd_word actually move a word on to the line 
to be printed. PROCremove_line first finds the space nearest the end of the 
screen line, line 1020, and then removes the whole of the string up to that 
space and assigns it to the correct screen array element. Its final function is the 
removal of that text from the remaining text that still has to be examined. 


Figure 10.31 
1470 DEF FNlast_space 
(string?,start_poas) 
19080 LOCAL found,space pos 
i@SO found=FALSE : space_pos=start_pos 
110@ REPEAT 
111@ IF MID#(strings,space_pos,1)= 
space? THEN found=TRUE ELSE 
space_pos=space_pos-—l 
1126 UNTIL found OR space _postl 
113@ IF space_pos*«i THEN 
space pos=start_pos 
114@ =space_pos 


This function searches a string, from the end to the beginning, until a space 
is found and returns the number of the location of that space. 


Figure 10.32 


1150 DEF FNnot_valid (word?) 

1166 LOCAL first? 

1170 first#=LEFTS (word?,1) 

1180 IF first#>"Z" OR firsts<"A" 
THEN =FALSE ELSE =TRUE 
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In order not to remove proper nouns, we check the first letter of a possible 
word to be removed and only if it isn’t a proper noun is TRUE returned. The 
comparison is a simple range check set to include all the upper case letters. 


Figure 10.33 

1190 DEF FROCinput_ move 

1260 LOCAL valid#,move? 

121@ valid#t="abcdefghi jkImnopaqrstu 
vw yz "+40¢+f 2$+lefttt+rights 

1224 VDU 28,0,27,29,24 

2o@ CLS 

1246 FROCcon 

1256 PRINT TAB(@,1)3;"Please enter 
choice —- "3 

1264 REFEAT 

1276 #FX2602 ,48 

i2a@ movet=GET+ , 

1290 UNTIL INSTRivalid?, moves) < >@ 

1200 FROCcoff 

1314 IF movet=left? OR movet=rights 
THEN PROCmove_position 

1320 IF movet>="a" AND move#t<="z" 
THEN FROCenter_word 

1336 IF movet=f0F THEN FROCprint_text 

1246 IF movet=f2s THEN finished=TRUE 

135@ ENDPROC 


This procedure is the master input routine and as such needs to allow for 


three types of input. Firstly we might want to move the current position of the 
cursor to another gap. This involves pressing the cursor arrow keys and is 
allowed for on line 1310. Secondly we might want to indicate that we have 
finished or, want to print the text out on the printer. This is indicated by 
pressing function keys ‘f2’ or ‘f0’ respectively and is allowed for on lines 1330 
and 1340. Finally we might want to try typing in a word, i.e. use the 
characters from ‘a’ to ‘z’; line 1320 passes execution to PROCenter_word in 
this case. The first part of the routine simply prints the prompts, sets the valid 
key-presses and inputs the option that the user indicates. 
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Figure 10.34 


1560 
i37@ 
1380 
139 
1406 


1416 


1420 
142.08 


DEF PROCmove_position 

LOCAL pos,vpos 

VDU 26 

FROCset location(current, yellow?) 
IF movet=left# AND current>l 
THEN current=current-li 

IF move#=rights AND 
current<last block-—il 

THEN current=current+l 

PROCset location(current,red#) 
ENDPROC 


The purpose and action of this procedure are easy to explain. If an arrow 
key is pressed then we need to change the position of the coloured marker. 
This takes two actions. We firstly need to set the current position to be 
coloured yellow, which is done on line 1390. Then we need to check to see if 
we are at the first or the last gap, in which case we cannot change position at 
all. Finally we can change the current position to be coloured red and then 
exit via the ENDPROC. 


Figure 10.35A 


1449 DEF PROCset_location 
Clocation,colour?) 

iOCAL pos,vpos 

pos=word position (tlocation,®@) 
vpos=word position(location,1) 
PRINT TAB (pos,vpos) ;colours; 
word valuet (location) swhites; 
ENDPROC 


1450 
14460 
1476 
1430 


1496 


After the last procedure has been called and the locations of the blank 
spaces computed this routine is called to insert the correct colour in the 
correct position. It simply moves to the location, prints a colour changing 
string, equivalent to a VDU 17 or COLOUR statement, then the word or 
blank followed by a string to set the colour to white again. 


Quer to You 


Figure 10.35B 


15060 
151@ 
1520 
1530 
15408 


15356 
135466 
1570 
1588 
is?7@ 
1600 
1610 
1620 
1630 
1640 
1658 


If you press the ‘f0’ key then you arrive in this procedure. It uses the 
FNprinter_on routine to ensure that the printer is connected and working 
before the output is sent to it. The VDU 21 ensures that printer output doesn’t 
appear on the screen. The second loop is used to call the formatting routine 
which can format output for the printer in a similar way to its action with 
screen output. After all the lines have been output the screen is turned on 


DEF PROCprint_text 

CLS 

REPEAT 
printer=FNprinteron 
IF NOT printer THEN PRINT 
"Please switch on the printer." 
""Press any key to continue." 
sinputt=GET? 
UNTIL printer 

CLS 

VDU 2 

¥DU 21 

FROCformat_ screen 


FOR loop=1 TO i2 
FRINT screens (loop) 
NEXT loop 

VDU & 

VDU 3 

ENDPROC 


again using the VDU 6 statement. 
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1666 
1476 
14680 
1690 
17846 
171@ 
1726 
1736 


DEF PROCenter _word 

CLS 

PRINT TAB(Q@,1)3 "Please enter word - “; 
word value (current )=FNinput 

CLS 

PROCformat_ screen 

PROCprint_screen 

ENDPROC 
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In this routine the actual words to fit into the gaps are input. The prompt on 
screen is changed as soon as you press an alphabetic key and FNinput is 
executed. Then the screen is cleared and reformatted to accommodate the 
new words, which are likely to be longer or shorter than the blank line that 
was in that position. At the end of this routine the screen will be filled with the 
text plus your new word, all formatted correctly. 


Figure 10.37 


9000 DATA"This book is meant to fulfil 
a dual purpose, “ 

9910 DATA"for besides trying to help 
you to write good, " 

90420 DATA"sound educational programs 
of your own, " 

9930 DATA"we also hope that it will 
help you to " 

904G@ DATA"“develop ideas about those 
programs you ”" 

9058 DATA"can buy and enable you to 
assess them "“ 

9460 DATA"in both educational and 
programming terms. ” 

9707@ DATA *###* 


You might recognize this test DATA as being the first few words of this 
book. We don’t suggest that you use this as a real test but it is sufficient for 
testing the program before you input your own DATA. 

There are three things to remember about the format of the data. Firstly, it 
must be terminated by four asterisks on a line of their own. Secondly, each 
line of DATA should end with a space. Thirdly, the last line of DATA, i.e. the 
one before the asterisks, must end with a space after a full stop. It shouldn’t 
need saying that the whole of the data must be able to be fitted on to twelve 
lines of the forty-column screen after formatting. A little trial and error should 
be used here. 

The following procedures should be added from the standard module 
library. 
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Figure 10.38 


14006 DEF FNprinteron 
12606 DEFPROCcoff 
<£@1@ DEFFPROCcon 


There is a shortened version of FNgpinput to be included too and this is 
printed below. 

Take particular notice of line 20030 where the string$ variable is not set to 
be a null string as usual but is assigned the value of move§$ to prevent your 
having to input that letter twice. 


Figure 10.38 
246600 DEF FNinput | 
264616 LOCAL deletes,return#, 
back space#,char#,strings 
24620 deletes=CHR$ (127) sreturn$=CHRS (13): 
back spacet#=CHR$ (8) 
40630 string#=movet : lenZ=15 
20640 PRINT STRING#(lenZ,".")5 
STRING? (len“é,back_ space?) s; 
246350 PRINT string#s; 
24666 REPEAT 
20670 #FX202,48 
~G0S50 char #=GET 
24090 IF char#=return? THEN 20140 
~010@ IF char$=delete? AND 
LEN(strings) -@ THEN 
string#=LEFT# (strings, 
LEN (strings) —1):PRINT 
back space#;"."sback_ space; 
:GOTO 26148 
261108, IF chars<"a" OR chars?"z" OR 
LEN(string#)=len% THEN 
VDU 7:GOTO 20146 
201206 PRINT chars; 
24130 stringt=strings+t+chart 
20140 UNTIL char%=return? AND 
strings<>"" 
20150 =string? 
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There are a number of problems in the debugging of this procedure as it 
won’t work in mode 1 in its unpacked state. Luckily there is another screen 
mode that we can use to test it before packing — mode 4. You need to change 
line 10 to read mode 4 and then save a copy before you go any further. The 
change of mode means that the yellow blank lines or words will appear as 
black and therefore cannot be read, but this is only temporary and will be 
rectified as soon as the program has been packed and returned to mode 1. 


Appendix 1 


Glossary of Terms 


It is beyond the scope of this appendix to explain the terms in detail. If you 
want full explanations of terms there are a number of good computer 
dictionaries available. Ask at your local bookshop for such a volume. 

The explanations given here are likely to be written with the two machines 
on which this book is based in mind. The details given will not necessarily be 
applicable to other machines or other versions of BASIC. 


address The number given to a particular location in the computer's 
memory where an item of information can be stored. 

alphanumeric All the symbols on the keys of the keyboard, more 
specifically the letters and number keys mixed and in any order. 

array An ordered collection of numbers (real number or integer array), 
bytes (byte array), or strings (string array), referred to using a single variable 
name and indexed using a subscript. They are held in consecutive memory 
locations and must be dimensioned using a DIM statement in BBC BASIC. 

AtoD converter An analogue to digital converter is a chip that can convert 
a range of voltages fed to it into a series of numbers ready for manipulation 
inside a computer. This type of circuit is the basis of the joystick port inside 
the BBC but can provide other functions too. 

baud A unit of measurement of information transmission speed often used 
as a shortening of ‘bits per second’, although the two are not strictly 
synonymous. 
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BASIC A language the computers can understand, written to be as close to 
English as possible, i.e. ‘high level’. This language is used on a number of 
microcomputers. The letters stand for Beginners All-purpose Symbolic 
Instruction Code. 

binary A numeric system with only two numbers, 0 and 1. It is ideally suited 
to computers whose memory is composed of vast numbers of switches that 
can be either on (1) or off (0). 

bit The smallest piece of information in a computer, shortened from ‘binary 
digit’. A bit can be only 0 or 1. See binary. 

Boolean algebra Named for George Boole, the nineteenth-century English 
mathematician, and fundamental to many aspects of computing: switching 
theory, logic design, logic itself, and aspects of algorithm design are subjects 
he considered. 

bug An error in a program that can be of two types. Syntax errors are bugs 
that cause the program to stop with an error message. Logic errors allow 
the program to continue but cause it not to perform as desired. 

byte A group of ‘bits’ that are often used as one unit. There are usually eight 
bits in a byte. 

byte array An array (see above) which can hold only numbers between 0 
and 255. This type of array takes up very little memory space and can 
therefore be used where other types of array would cause problems. 

cassette The usual method of storing programs for later use. Identical to 
music cassettes, computer cassettes are often much shorter to stop the 
need for a great deal of rewinding to find a program. 

chip A slang term for an integrated circuit, i.e. a pattern printed on to a 
small ‘chip’ or piece of silicon metal crystal. Most computers are made up of 
such chips, which can replace huge numbers of transistors and other 
electronic components. 

crash Slang term for a program that has gone wrong in some way, i.e. it is 
said to have crashed. Sometimes a crash can be so serious that the 
program is lost completely. 

cursor A flashing line, which can be tumed off, that indicates where the 
next piece of information or character will appear on screen. 

envelope The type of change that can occur to a sound being produced by 
a computer or other musical instrument. There are two parts to an 
envelope: the pitch envelope, i.e. changes to the frequency of a note, and 
the amplitude envelope, i.e. changes in volume. These changes are 
responsible for a particular instrument having its own characteristic tone or 
timbre. An envelope can be defined, on a BBC or Electron, to produce a 
whole range of effects. 

flag A variable used to show that a particular condition has been met. Often 
used with just two values, a logical TRUE and a logical FALSE (—1 and 0 
respectively in BBC BASIC). 
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flowchart A diagramatic representation of the flow of logic in a program. 
Usually made up of geometric shapes connected by arrowed flow lines. 

function (FN) A part of a program that can be defined to return a numeric 
or string value when called by name. Certain functions are built into most 
BASICs such as SIN and PI, others can be defined by the programmer 
using the DEF FN statement. 

function keys Keys on a keyboard which instead of having a set function 
can be changed by a program or command to take a desired action. 
Sometimes called ‘soft keys’, as they lose their definition when the memory 
is lost, for example when the machine is turned off. 

glitch A bug caused by a voltage surge or electrical noise. They can travel 
around a mains electrical circuit and cause untold problems when a 
computer is connected. 

graphics mode After using a VDU 5 statement the screen is said to be in 
graphics mode. All printing will then be done at the graphics cursor, and 
PRINT TAB may not be used. 

integer array A numeric array (see above) that can hold only whole 
numbers, not decimals. 

interface The junction between two separate pieces of equipment, for 
example a computer and a tape recorder, which would be called a ‘cassette 
interface’. Many types of these exist and the BBC has a large number to 
cope with the vast range of jobs that it can be programmed to do. 

K An abbreviation of ‘kilobyte’, often thought to be a thousand bytes. 
Unfortunately 1000 is not a power of 2, i.e. not easy to represent in binary; 
so in computing ‘kilo’ represents 2 to the power 8, or 1024. This is often 
used as a measurement of computer memory, the BBC and Electron each 
having 32K memories, or 32 times 1024 memory addresses, i.e. 32,768 
locations. 

keyboard buffer Whena key is pressed, the ASCII code of the key is placed 
into an area of memory with this name. It stays there until removed in some 
way or until the buffer is flushed, i.e. cleaned out. 

looping structures Methods of programming that cause the flow of a 
program to execute the same sequence of instructions a number of times. 
The number of executions can be fixed, as in a FOR/NEXT loop, or 
dependent upon a condition being met, as in a REPEAT/UNTIL or 
WHILE/WEND loop. 

machine code _ The instructions that a computer can act upon when fed to it 

-as a stream of different voltages, each representing a 0 or a 1, i.e. a binary 
code. High level languages, like BASIC, need to be translated into this type 
of code before the computer can act upon them. This is called interpreting 
the language and is done by a program called an interpreter. 

memory mapping Screens are often referred to as memory mapped if their 
contents are held in a particular position in memory. This means that if you 
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modify the memory contents in some way this will be shown on screen 
when it is next printed. | 

modes The various configurations that the screen can be set to. The BBC 
has eight and the Electron has seven of these modes; see the user guides 
for a full description. 

modular form A method of programming in which a large -program is 
broken down into smaller functional parts, each part having a carefully 
defined purpose. 

nibble A part of a byte, usually four bits. This means that there are usually 
two nibbles to a byte — makes me feel hungry whenever I read it! 

numeric The numbers that we use in the decimal number system. ‘Numeric 
input’ means the input of a series of numbers, and this excludes all the 
alphabetic keys. 

operating system A program inside a computer that deals with all the 
‘housekeeping’ needed and which handles the communication between 
the computer and its users. 

paged ROMS A method of adding more memory than an eight-bit 
microprocessor can address, which relies on rapid switching, i.e. paging, 
between memory segments. 

PAL A type of modulation of a video signal. This particular type is used in 
British TV broadcasting, other countries using other types of modulation. 
This means that a PAL-modulated computer can be used only on a British 
specification TV. 

parameter Information that is passed to a procedure or function, which can 
then be used or manipulated within that part of the program. 

peripherals A device of any type that is connected to a computer, such as a 
screen or a cassette recorder. 

pixel plotting A pixel is the smallest point of light that can be plotted on the 
screen, i.e. a dot. Using such dots, any shape or picture can be built up on 
the screen. 

printer dump Any information passed from a program to a printer. Often 
used to refer to the printing out of the screen contents. 

procedure A part of a program identified and called by its name. It usually 
has a highly specific function to perform and can receive parameters when 
called. 

program A series of instructions or commands, in the correct order, that will 
cause a computer to carry out some desired function. 

program location BBC BASIC allows you to choose where programs are 
located in its available memory. They are usually located at PAGE, which can 
be set to any memory boundary value. The user guides give more details. 

RAM Random Access Memory. You can both read and write, i.e. change, 
what is held in this type of memory, which would have been better named 
‘read/write’ memory — for all memory can be accessed randomly. 
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real number array An array (see above) that can hold real numbers, i.e. 
numbers that are positive or negative and can have decimal parts. 

RGB. A type of video signal output in which each colour, i.e. red, green and 
blue, is fed down a different wire. It usually gives a high quality display. 

ROM _ Read Only Memory. This memory can only be read from and cannot 
be written to. This type of memory is retained when the machine is turned 
off. 

scroll What happens to a screen of information when more is printed at the 
bottom: it scrolls upwards. Cleverly written programs can also make 
information scroll downwards, sideways and even diagonally across a 
screen. 

sideways ROM See paged ROMs, above. 

sceftware Programs which control the action of a computer. These are often 
held, or stored, on cassette tape but can also be held on paper, in chips or 
even as electrical signals. It is the information that is the software, not the 
method of storage. | 

spooling A method of storing a program in ASCII format, instead of in the 
more usual internal format used by BBC BASIC. Spooled files can be 
added to programs very easily using the *EXEC command. 

string array An array (see above) containing an ordered set of strings. 

string input The input of a series of characters, i.e. letters, numbers or 
symbols, from a keyboard. 

text mode The mode entered by default when a mode is selected and after 
using a VDU 4 statement. In this mode text is printed at the text cursor 
which can be moved using the PRINT TAB syntax. 

toolkit Programmers’ toolkits, far from being physical objects, are a series 
of programs that make program development easier. They might contain 
special search-and-replace routines and line mfiovement routines among 
many other features. 

TUBE A registered design of interface that allows particularly high-speed 
communication down a series of data wires. On the BBC it allows the use 
of a second processor and can speed the BASIC considerably. 

user friendly A feature of a program which suggests that it requires no 
previous knowledge of how to use it, all the instructions being given when 
required. A program on which it is very difficult to make a mistake. 

user input Anything that the user of a program is required to type. 

user port One of the interfaces on the BBC computer. This can be used to 
control a series of switches or relays. 

WHILE/WEND AA loop structure not provided in BBC BASIC. The 
difference between this and REPEAT/UNTIL is that the condition is tested 
at the start of the loop, not at the end of it. 

white noise A noise made up of all frequencies; it has interesting effects 
when manipulated. 
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word processor A program that allows the typing of text into a computer- 
type memory which can then be altered and revised before being printed 
out on to paper, and which can make any number of identical copies of the 
information given. 

*FX A method of changing the ways the computer takes certain actions by 
altering features of the operating system. These calls allow the selection of a 
variety of printers and the flushing of buffers, for example. 


Appendix 2 


Useful Addresses 


Machine manufacturer 


Customer Services 
Acorn Computers Ltd 
Fulbourn Road 
Cherry Hinton 
Cambridge 

CB1 4JN 


BBC 


Computer Literacy Project 
PO Box 7 

London 

W3 6XJ 


Micros and Primary Education (MAPE) 


MAPE Secretary 

Mrs G. E. Jones 

76 Sudbrooke Holme Drive 
Sudbrooke 

Lincoln 

LN2 2SF 
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Micro-users in Education (MUSE) 


MUSE 
Freepost 
Bromsgrove 
Worcs 


BEEBUG and ELBUG (national user groups) 


BEEBUG/ELBUG 
PO Box 109 

High Wycombe 
Bucks 

HP10 8HQ 


Microelectronics Education Project 


MEP 

Resources Centre 
Newcastle Polytechnic 
Coach Lane Campus 
Newcastle Upon Tyne 
NE7 7XA 


The authors 


Dave Carlos/Tim Harrison 
c/o Papermac 

Macmillan London Ltd 

4 Little Essex Street 
London 

WC2R 3LF 


Appendix 3 


Typing in the Listings 


Typing listings is never an easy job and there are many pitfalls which we all 
succumb to now and again. It is easy to blame the listings or the writer for the 
fact that a program won’t work, but on most occasions the reason for a listing 
not working correctly is that the person who typed it in made a typing error of 
some kind. We have typed in many listings over the years and have made just 
the kind of mistake that you make. There is, therefore, a great need to 
develop ‘debugging’ skills, i.e. learning what the various error messages mean 
and how they are caused. The section on debugging aids covers this area in 
great detail and should be referred to if you are in difficulties. 


General advice 


When you are typing in a listing try to have the area well lit and the book flat 
on the desk beside your computer. It might need holding open in some way 
and we would suggest that a ‘bulldog clip’ is ideal for this. In order to keep 
your place easily we recommend a ruler of some type. The one we use is a 
special magnifying ruler with a line marked across the centre; when this is 
placed on the text we can position the marked line on the line we are typing in 
and then read it through the magnified section of the ruler. It really does help 
a great deal and prevents many errors. There are also some book stands with 
magnetic or plastic rulers to mark your place; these might be useful if you 
have the room for them. 

Don’t try to do too much of a listing at once. You will make far more errors 
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than if you were to do small sections and take frequent breaks. The breaks 
can become useful if you use them to save everything that you have typed so 
far. This means that if any disaster should befall your computer in the 
meantime you haven't lost everything you typed from the beginning; all that 
you need do is reload the last version and carry on from where that ended. If 
you follow this method it is impossible to lose everything when the cat sits on 
the BREAK key, or the fridge switches on and sends a ‘glitch’ that wipes out 
the computer’s memory. | 

Adopt a naming and numbering system for these partial and incomplete 
versions. Devise your own method, or copy this one: 


File title 
Style Meaning 
lower case Un-debugged partial version. 


Initialized lower case Finished version but still some bugs. 


UPPER CASE Final debugged version which has been test-run. 
Numbering of files 

Number range Meaning 

0.10 to 0.99 Unfinished versions that don’t work. 

1.00 to 1.99 Complete and debugged versions being 
adapted. 

2.00 to 2.99 A different adaptation of the program in its 
development stages. 

3.00 to 9.99 More, different versions of the same base 
program. 


By using this system, there is no need to list a program to see what stage it is 
at. Under ‘1’ and it must be incomplete; over ‘1’ and it should be a working 
version. This can be confirmed by the lettering too, but be careful if you use 
disc drives, as the names ‘Fred’, ‘FRED’ and ‘fred’ are all taken to be the 
same by the DFS, and it will happily overwrite one file with another and scrap 
valuable work. Always use numbers too! 

There are two types of listing in this book and they need to be treated 
differently when you have typed them in and are ready to save them on to 
tape or disc. The first type of listing is those that comprise a complete program 
listing like ‘Humber’. These programs should be SAVEd in the normal way so 
that you can reload them using the LOAD or CHAIN commands. You should 
save them one to a tape, labelled carefully, when they are debuaged, so that 
you don’t have a lot of rewinding to do to find the right program. This is the 
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reason that computer tapes are very short: you are expected to keep just one 
program per tape, though it is always a good idea to record two copies in case 
one gets damaged. Whilst you are typing in a listing like ‘Humber’ you could 
use a longer tape and keep all the stages one after another; then you simply 
rewind to the last one as needed. Disc users should always have a formatted 
disc ready before starting typing — you don’t want to lose all your work by 
having to format a disc! 

The other type of listing comprises the modules that we suggest you use in 
your own programs. These are all incomplete in that CHAINing them will 
cause only error messages to be produced. Whilst it is possible to SAVE these 
part-programs in the normal way, it isn’t the best way by any means. We 
expect that you will want to keep these programs in some type of ‘module 
library’ ready for use in your own programs, so you need to store them in 
such a manner that you can easily add them to programs you are developing. 

The method we suggest you use is to keep them stored as ASCII files on 
your tapes. The way to store such files is explained in the user guides in the 
section on ‘Merging BASIC Programs’ (BBC p. 402, Electron p. 200). The 
technique is as follows: 


1 Type in the module as normal, then debug and test it. 

2 After you are sure it works properly, *SPOOL the program to your 
tape or disc using the following command sequence (each line 
should be typed as shown and ended with RETURN): 


*SPOOL program_name 


The final *SPOOL is essential as it closes the file and clears 
everything out of the buffer. | 
When you typed the LIST the program should scroll up the 
screen as normal. Whilst this is happening, though, all the characters 
are being written to the tape or disc too, so the listing won’t be as 
quick as usual. If you were in ‘paged mode’ when you gave the 
command you will have to hold the SHIFT key down at the end of 
“every screen of information. This allows the writing of the file to the 
media to continue, although it would be best to turn ‘ paged mode’ 
off (VDU 15 does this) before you type the commands. 
3 Label or mark on the cassette or disc clearly that this isa *SPOOLed 
file and should be reloaded using *EXEC not LOAD or CHAIN. 
4 Either repeat the operation on the same tape or write another copy 
to a different tape in case of accidents. 


Now you have a file which contains all the characters in the listing in ASCII 
form. This means that when you *EXEC this file it will be read by the 
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computer in just the same way that your keyboard is read. The computer 
behaves as if you typed all the information in from a keyboard and the 
program lines are added on to the program already in memory just as if you 
had typed them. Don’t worry about the two ‘Syntax Error’ reports that always 
appear on the screen. They are due to the *SPOOL operation but will never 
ruin a program. 

By building up a library of such files you can easily add any module you 
need to a program you are developing. If you use the type of planning that we 
suggest, you will know which ones you need before you start, and can 
therefore add them at the beginning of the programming session. 

This is the main reason for keeping to the same line numbers that we have 
used, as they are all unique to the procedure as printed. If you ever use a line 
number in this range and then *EXEC another line with the same number the 
old one will be wiped out of memory and the new one will take its place. If 
you are prepared to use line numbers below 9999 for your own programming 
there should never be a problem. 


Listing style 


In this book, so that the listings fit neatly on to a page, there are never more 
than forty-five characters to each line. This means that lines such as these: 


Figure A3.1 

100006 PRINT "This is a demonstration of 
the way that programs in this book are printed." 
1001@ PRINT "We hope it helps you to type 
them into your computer!" 


will be printed in the listing like this: 


Figure A3.2 


14006 PRINT "This is a demonstratioan 
of the way that programs in this 
book are printed." 

1@01@ PRINT "We hope it helps you to 
type them into your computer!" 
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It is essential to press the RETURN key only when you are due to type 
the next line number and not after each line as printed in the book. In the 
example above you would press RETURN only just before you got to the 
second line number (10010). 

The listings were also produced with the LIST Option set to 7 (LISTO 7), it 
is explained in the user guides (BBC p. 290, Electron p. 164). This makes 
loops obvious by indenting them by two spaces and places a space after each 
line number. There is no need to type them in this way, though. A great many 
of the spaces can be omitted without any errors being caused. Take the 
example below, which is as you would find it printed in this book. 


Figure A3.3 

11906 REPEAT 

11010 FRINT "This is an example of 
nested loops." 

11026 FOR counter = @ TC 10 


11030 PRINT counter 
11649 NEXT counter 


11056 PRINT “Outer loop again!" 
11060 UNTIL FALSE 
110@7@ END 


We hope that this makes it easier to see the structure of the program, but 
there is no need to type all these spaces. They use up far too much memory if 
you do. So we would expect you to type this program in like this: 


Figure A3.4 


11@Q@@QREPEAT 

L11@1@PRINT "This is an example of nested laops." 
11920FOR counter = @ TO 1@ 

Li@S@PRINT counter 

LIG@4ONEXT counter 

11@S@PRINT “Quter loop again!" 

LIG6QUNTIL FALSE 

1107@END 
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There are still some extra spaces in these lines, though. To take line 1 1020 as 
an example, this could be typed as follows — but notice how difficult it is to 
read properly: 


Figure A3.5 
11@20FO0Rcounter=@T010 


Most of the listings have been prepared so that you can use the automatic 
line numbering facility (AUTO). All you have to do at the start of a listing is 
type ‘AUTO 20000’, where ‘20000’ is the starting line number, and you 
should be able to type the rest of the listing in without any line numbering 
problems. Use the line numbers we suggest: don’t start every listing with line 
number 10 or the *EXEC command will wipe out your original program. 

Another problem you might find is that the variable names are mostly in 
lower case. This is so that they are easier to find in a listing and indeed make 
the listing easier to read. Leave these in lower case, as changing them to 
upper case could cause difficulty. Take a variable named ‘value’ as an 
example; if this was typed in upper case as “VALUE’ there would be problems 
because ‘VAL’ is a BASIC key word and would be understood by the 
machine as that word instead of as a variable. Integer values are always 
ended with a ‘%’, and although they can often be exchanged for real 
variables there are occasions when this is not a good idea as the program 
might react differently using real variables. So use the integer sign wherever 
we have done so. Changing anything from how it is listed in the book is a 
guaranteed way to introduce errors; avoid it if at all possible. 

In case you find all this advice a little daunting, the typing in of listings and 
subsequent debugging is a good way to learn more about programming. Our 
computer club recently held a debugging night where everyone was invited to 
try to find the errors in a short program. It was so popular that we had to give 
more time at the next meeting so that everyone could have a turn and then 

have all the errors explained. All the routines and programs in the book have 

been well tested and printed from a working version of the program. If you do 
find any errors please let us know, via the publishers, and we will correct them 
as soon as possible. 
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